These are questions for wise men with skinny arms

Simplicity - the art of maximizing the amount of work not done, is essential. Most teams simply don’t spend enough time on this. A sense of urgency often overrides careful planning. The problem here is careful planning makes things get done faster. During the planning stage it feels like you’re not getting anywhere, but you are setting up for a quick sprint. This setup is often overlooked, and we end up with not only complicated software, but complicated development habits, complicated code, and generally poor software design.

Knowing something is possible does not make it easier, it just makes it more frustrating when it doesn’t work the first few times. This even goes for things you already know how to do. Putting the pieces together is much more difficult than the design. It’s true that a good design can help the pieces fit together seamlessly, but ‘bad’ designs can have the simplest implementations. Then what makes the design ‘good’ isn’t the ease of implementation, it’s the reliability, impact, and extensibility of the completed system.

So I’ve been spending an inordinate amount of time on IT related activities lately, and boy have I gained some respect for people who do this everyday. My very first jobs when I was a kid were essentially help-desk level IT: setting up networked printers, digging through backups, making cables, removing viruses, installing drivers, and using more advanced Windows tools to automate things. These were all things that I could do because I generally had no real insight into how computers worked or how to program.

I spent most of today reading Julia documentation. It looks pretty slick, but I guess I’ll have to try it out on something new to really kick the tires. It does strike me as more of a hyped up Matlab instead of a JIT’ed Python. For a new ecosystem I’m a little concerned that it might be too much too soon. It has all the shiny things about being a new language, like consistency and lots of involvement, but I don’t know what will keep fueling the momentum.

So I’m clearly late to this party, but I just find this too funny. Tech marketing tactics have bled into other areas with expected results, hilarity. It wasn’t long ago I saw the video for books for kids video that called all of the silicon valley gadget fetish for what it is. The video was cute and ended on a warm note that people should get as excited about education initiatives as they do about consumer electronics.

I found my boss’s old programming blog. He’s much more practical in his writing than I. It starts at his job search experiences and then moves into his discussion of introductory coding experiences. The posts are very focused on process and application, never mentioning a specific language or technical details(Two things I’m keen on detailing!). It’s clear he also spent some time reading Yegge and books on best practices. He discusses these practices through his book reviews, much like my blog reviews.

Soft errors require more finesse to avoid. Carefully aiming before attempting to blast down the problem will save time and frustration, although nothing beats the experience of trying all the possibilities. I spent the last few days setting up automated e2e tests with node for Angular. I hadn’t done any real back end JavaScript, so I was learning how to put together grunt tasks with a node server. The problem was simple enough: start a proxy authentication server that registers with a central authority and point the tests to use the temporary proxy server.

I spent the weekend reading every post on M O. C’s blog, I’m starting to read more about code than write it! Some of it was insightful, although he does grind the same few axes over and over. I often felt like he was parroting other people with similar concerns rather than speaking from his own experiences. His real insights were hidden in his hyperbolic criticisms, he didn’t pull any punches when talking about how 95% of software gets made.

Debugging and refactoring go well together. I spent the past few days bug hunting near the end of a release, and I took the opportunity to address all the todo comments as well as buggy behavior. A task that started off as simply removing a library that wasn’t being used anymore lead into a more serious refactoring of the database interface that exposed a few latent bugs. During the long build cycles, I again tried to go through the Learn You A Haskell For Great Good, but I found that I just wasn’t absorbing it without the ability to test it out.

For my annual review I had to recall what I’ve done well and where I need improvement. Previously I used my notebook with my //todo lists and debug ideas to evaluate what I was working on and how well I did. This worked great when my projects were small enough in scope that I had design and debugging notes for each part that I accomplished. It was easy to see when and where I had problems and then address those issues accordingly.