Daily work log

Like a lot people I regularly have the problem at the end of a workday or even a workweek answering the question, “What did I do?” let alone what “What did I accomplish?” To find an answer for these questions I have started to keep a daily journal using both an automated report and a manual entry.  Between these two entries I tend to have a good idea of what occurred during my workday and work week. The idea to keep a journal was inspired in part by a post over at Productivityist: Taking Journaling to Another Level. It is useful to note that I am a Mac user so all off the tools that I use and have strung together to generate my automated report are Mac specific. That being said, I have found this this practice to be very helpful in keeping track of what I am or am not accomplishing and use it in concert with my daily and weekly review.

Screen Shot 2014-11-01 at 15.44.17I started this project by writing the automated script using an AppleScript that glues together all of the various apps I use (Mail.app, Omnifocus, Lync, and Apple Calendar) and generates an automated report of what email I sent, tasks I completed, my scheduled meetings and people I interacted with over IM. There were some limitations on what I could actually pull out of all the various apps, but in the end this is high-level list, if I need more I can the app that has the information I need. I kick off this script when my workday comes to an end and the script will collect all the data and stuff it into a new entry for the day in Day One.

After using the script for a while I would still have a lot of those “oh yeah I did XYZ task that day” moments when doing my daily and weekly reviews. The items I was not capturing were items such as phone calls, general thoughts, gripes, or half done tasks that may not show up in any of the apps I collect data from. This eventually led me to keep a daily journal entry in Day One along side my scripts entry. These entries maybe something as simple as a few bullet points I add over the course of the day, or something more detailed along side of the basic thoughts.

Reviewing these two entries feeds into my own daily and weekly review of my to-do lists to figure out what needs to be put in the list for tomorrow or a later day. A by-product also this simplifies a weekly status I report for my manager. These reports also provide me a view into items that have been touched in the many projects I have running concurrently and random tasks that come in through all of my various inboxes.

I recommend this practice for anyone, it can help you feel more accomplished, remember those ideas you had that you couldn’t do anything about, and vent about the frustrations. I also find it helps me see what all I have accomplished even when my to-do list does not get smaller or items did not get completed when I planned them to be completed. You can download a copy of my daily script can be found in my Github at,

https://github.com/suidroot/workprojects/blob/master/Daily%20Report%20to%20DayOne.scpt
I implore you to not laugh too hard; this script has been hacked together with a lot of twine, glue, and duct tape, and has been my first attempt at AppleScript.

Footnote: This post was inspired in part by an Engadget post about DayOne.

My interest of academics of systems

Lately I’ve been very interested in academic side of computers. Complex systems, Theoretical Computing, and Control Theory are two of my focuses right now. This has come about because I’m getting more interested in how the systems work and how ti measure them, more then how to implement them. My career has been very focus on the implementation then how systems work and can be measured. I’ve never had any sort of formal Computer Science education, making a lot of this new territory to me. As I dive deeper into these topics I realize how much math I have forgotten over the years. These topics are some of  reasons for me to refresh my math skills, however math skills are also analyze sampled data such as monitoring data. A great video discussing data analysis is by Noah Kantrowitz at Monitorama PDX 2014.

Monitorama PDX 2014 – Noah Kantrowitz from Monitorama on Vimeo.

Some of the topics I’m learning about are much broader then others. The definitions of these fields of study as defined by their Wikipedia articles are as follows,

Control theory is an interdisciplinary branch of engineering and mathematics that deals with the behavior of dynamical systems with inputs, and how their behavior is modified by feedback.
Wikipedia: Control Theory

The field of theoretical computer science is interpreted broadly so as to include algorithms, data structures, computational complexity theory, distributed computation, parallel computation, VLSI, machine learning, computational biology, computational geometry, information theory, cryptography, quantum computation, computational number theory and algebra, program semantics and verification, automata theory, and the study of randomness. Work in this field is often distinguished by its emphasis on mathematical technique and rigor.
Wikipedia: Theoretical Computer Science

Complex systems present problems both in mathematical modelling and philosophical foundations. The study of complex systems represents a new approach to science that investigates how relationships between parts give rise to the collective behaviors of a system and how the system interacts and forms relationships with its environment.
Wikipedia: Complex Systems

All of these topics I feel are important as products start to become much simpler and centrally controlled or incredibly complex in their interactions. Algorithms, controls, and data are becoming more and more important to understand.

How I started and learned (Hello World!)

I think it makes sense to kick off this blog with a how did I get to where I’m at today. This post covers about 16 or so years (as of posting) of working in IT and Computers and well many years before them as a well….hobbyist.

My first introduction to communications, I guess you could say networking, was calling BBSs and eventually installing and playing with BBS software. I learned a lot about modems and dialup communications. Towards the end of this era (to learn more about this time in technology I highly recommend watching the BBS Documentary that was released by Jason Scott in 2005.) I leaned about 2600 Magazine and went to a 2600 Meeting in my area and starting to get interested in the Phone System and how the Phone Switching Systems work.

Then came along the internet, and I started to learn about programing in some classes in High School and on my own, eventually learning C Sockets and coding some basic Client/Server programs and showing me how applications worked across a network. At this time I didn’t know anything about the 7 layer model or another really about networking theory, but I do know now this knowledge has shaped how I have always approached troubleshooting.

Eventually I decided it was time to get a job working on computers and  I found a job working for an outsourced call center for a major home computer manufacturer. This was a very valuable job in my career, here I learned one of the toughest skills to learn, customer service. There were many difficult customers, for example, “where the Start Button?”, Sorry your hard drive is clicking and your data is gone, ‘Yes, click the mouse button in the right” are just some examples. I learned to handle and lead non-expert users, and resolve there issues to the best of my ability. Doing it all with a smile in my voice no matter how frustrating they were.

Eventually that job ended (ahem laid off) and I moved into a job and small computer integration company (see Thoughts on Working as a Consultant for a VAR and THE VAR-Y GOOD UPSIDES TO BEING A CONSULTANT! both are true in a lot of ways about a 13+ years ago as they are today). On my first day I walked to a stack of Novell NetWare books. So I learned NetWare, then Windows NT, Windows 2000, the desktop OS of the month, how to run cable (badly), and just about anything you could imagine in a small company would use at that time. This made me a  very well-rounded technician but not too deep any topic. I did always have a feeling I had an interest in the networking, so I made every opportunity I could to learn how to program routers and learn networks.

After enough time I studied and got my CCNA at the same time as my boss/owner of the company at the time. This is when I fell off the deep end and started to become a specialist in networking and connectivity, learning about T1s, factional T1s, 56k circuits  working with phone companies, still running cabling, routers, switches and still doing all the server work when needed. Then the craze of IP Telephony hit and we started to install Cisco CallManager and Unity. Learning more about PBXs, call routing, dial plans, and auto attendants then I’d ever cared too. Some where in this time period I’d say i could be calling a Network Engineer and moved up form just being a Technician.

After long enough I decided it was time to get my CCIE, then I procrastinated a while and then I actually did my Written exam and then Lab exam. It was a lot of work but I got it done with a stack of Cisco 2600s, and a lot of late nights. Not long after this my work role changed a lot moving into a role as an IT Director, where I still did my fair share of engineering, but also dived into security and operational policy for internal IT along with our virtual co-location data center (what we would call IaaS now) that we built from the ground up which was very fun. This more or less leads me to today where after more role changes I now focus on Network Architecture for on site customer networks as a Managed Service Provider and the network for our Cloud Service we provide. Working more in diagrams, word, excel and documenting now then working in actual commands lines.

Not to wax poetic too much but it was been a long winding road, and all the change along the way has kept me on my toes and kept it interesting.