Overview 2015

In 2015, I started drawing things that I wrote about. I also started writing a whole bunch more. Here is an overview of some of what I wrote during the year, including all the illustrations.

Leadership and Workplace #

Team Leaders Should Shield Developers was my first claim about leadership. It is impossible to get anything done while being constantly interrupted or while under constant pressure. It is the (tough) job of Team Leaders to deal with the pressure, and relieve the developers of it, I argued.

In the image above, a Team Leader is at a meeting while the developer gets some work done.

In Workspace Ownership, I argued that the best work is done in a workspace where the developer feels comfortable. Comfortability can, for example, be achieved by allowing fun (and useful) activities, such as pingpong, in the office.

Most popularly, in this category, I wrote about what I learned from my first job in Software Development. The post was called Lessons From Past Jobs (1), the “(1)” indicating that I will probably write about later job experiences at some point in the future. I mean, the post was popular.

For Lessons From Past Jobs (1) I had a few different possible illustrations, but ended up going with the one shown first here (the developer sending an email instead of making a phone call).

The other illustrations are a manager asking “Are we agile yet?” and a manager who values false communication, respectively.

Lastly, I have been fascinated with the debate about The Zone, that myserious and magical place where some developers go for spurts of productivity, and the arguments for and against going there.

I wrote about this, and put a spin on it, in Group Flow in Software Development.

The spin in that post was mostly connecting the dots from the research on flow and group flow to the new and quickly growing (at least in popularity) practice of MobProgramming.

I tried to briefly describe MobProgramming in the post, but evidently wasn’t precise enough — Woody Zuill reached out and talked to me about the definition. I never got around to making a correction in the actual post, but if the concept of being multiple people working on the same code (and not just two as in pair programming) you should check out the great writing on MobProgramming.com.

Process #

I sometimes feel like some people have a great aversion to the word “Process”. And I can understand that: it sounds big and bulky and bureaucratic.

But minimal process is also process. Process is “how you do things”, so the only way to not have a process would be to not do anything.

Software development processes follow naturally from discussing leadership and workplace. In fact there is some overlap.

Scrum is one of the most well-known Software Development Processes out there today. I don’t know a single developer who doesn’t have some idea of what Scrum is. Still, I wouldn’t recommend Scrum, I wrote. Simply because it relies heavily on concrete actions to be taken, rather than the ideas these actions are derived from.

I would recommend that any process be founded in thoroughly-discussed values. Start with the values and constantly reevaluate the concrete actions you take, and see whether they fit in with the process.

One value that I think all Software Development should share is communication. How that communication is manifested depends on the specific work environment, and in Face-to-face Communication: a story, some thoughts I tried to discuss some of the pros and cons of working remotely versus working colocated.

In Do Unto Yourself (which I tried to illustrate with some guy ruffling his own hair the same way he ruffles someone elses hair) I wrote about a different value, namely Integrity (or maybe Accountability?), in that the software you produce is software you would use. If you are building something you find absolutely useless it probably won’t be a good experience for the end user either.

Very much along the same lines (touching on the same values) was Teach people to do the Good Thing, in which I used an attic door as a metaphor for code.

The Good Thing is kind of a spin on the good old Boy Scout Rule, which originated with Uncle Bob.

Knee-Deep in Code #

As any good software developer would be, I am knee-deep in code on a daily basis. As a result of this, quite a few of my blog posts are code specific, ranging from notes and snippets to principles and measurements.

I wrote that I prefer if-return to if/else, that the code for a web app’s endpoint should do exactly three things, and I discussed Uncle Bob’s Clean Code principle that function names should be exact—I prefer them positive. I wrote a long thing that was mostly an angry rant at a Javascript interface (specifically bind).

On Web Apps #

I have been writing quite a bit about web apps.

I think web apps should be at the very front of your apps, making it easy to replace them. Web apps are basically user interfaces to your business logic (albeit advanced user interfaces). I also noted that I think web apps should be composed out of smaller web apps, each exposing its own bit of business logic.

I tried to illustrate the reader as an art connoseur making the choice between centralized and decentralized routing, eventually settling on the latter. This is what the illustration above shows.

On a very connected note, I discussed different ways of routing, recommending routing in a decentralized manner: each sub-app should decide its own routing.

I did a few comparisons of different ways to render web apps (and then clarified what I meant by rendering).

Comparing ways of rendering was mostly done in preparation for something bigger I am working on (dynamic web apps with built-in, nuanced caching), and that I am having a hard time capturing in blog post form. I did elaborate a bit, writing about static pages in dynamic web apps, which presents an early and crude prototype of the greater concept I am working on. More on that in 2016.

Software as Subject #

What is software? What is its place in the world? How do we build systems, version them, make them maintainable?

I tried to clear up what I think software is and how it relates to code in Software Is Never Finished, Code Can Always Be Improved. “Software consists of code and code builds software, but they are two different things at separate levels of abstraction,” I write, trying to establish a more concrete language before trying to argue the truth of “software is never finished”.

As you are building a system, it develops a personality, I also argued, and getting to know this personality is paramount for understanding which directions the system can and should go in.

I wrote about versioning, and how deciding on how to version a piece of software is a more nuanced decision than “we use semver” or “we do not use semver”: it depends on the size of the project.

This next illustartion was for On Versioning, but was never published. I didn’t like it at the time.

Finally, in my most popular post of the year, I wrote of a concept I call Pushing Complexity, the act of—at all levels—making it easy to get an overview. Helping new developers understand your code base/project structure/organization simply by making sure that there are fewer things at each level of abstraction.

These folks are getting to work, pushing out that complexity. You can, too.

Something, something this form, something, something updates when I write more, something, something.