The Meta Skills of Software Development

An early job I had in software engineering was at a consulting firm; we primarily did front end stuff for companies who had solid back-end teams. One of our biggest clients took up probably close to 60% of my work focus while I was there and this is what my takeaways are from that time in my career.

Soft Development Skills - Planning

The level of thought, planning, and thoughtful methodical execution that was put into things before ever touching code has still not really been matched in any of my roles thereafter. Most often the two of us (we were both fairly junior) on the project were working on the technical design/ticketing for an entire day with breaks.

It was mentally taxing of course, but it all got done (with lots of coffee and yerba mate of course) and we had solid, mutable plans for the next long while, somewhere between one and three sprints. We also created ticket-able notes and artifacts which we would use in a short presentation which we would make together to our principal engineers, if not our peers as well.

The planning tasks were designed to help us to level up as we learned how to:

• “interrogate the design” and find gaps in the use cases that needed further design development,
• think of surface areas of the application where bugs might be likely without extra attention,
• and identify the areas of most uncertainty amongst the parts of the application or planning or end result or whatever, and be ready with solid mutable response ideas.

The pair planning aspect of it has several advantages, many of which are related to attention span and duration, as:

• neither of us could play with our phones at all, as we each felt a debt of attention to the other person. We’d actually get “in the zone” and time would fly by, on a good day.
• we’d both idea-check the other during the planning, which was further proof that we were highly focused, but could still see the same forest and the same trees.
• we’d developed a semi-formal lexicon to specify what parts of the application we were talking about. There was very little uncertainty in communications about what the other person was talking about.

Writing Code, Planning and Review and Execution

If you were to create an artifact of planning or order of execution, what would that artifact look like? Would you refer to it close to half the time? If so, then it’s worth spending serious time planning the task, without jumping the gun and into writing code.

With regard to code style, elegant code is usually good code. Is it “perfect”? Of course not, but make it easier to debug later, please. Let’s make this code as boring and readable as possible.

DOCUMENT your patterns. It might seem dumb to set prose in your editor as ‘the code basically speaks for itself’ but does it really? I think that’s just your writer’s block. Writing good prose about your code is also writing good code. In the comments, point out briefly things that are not obvious from reading the code, don’t just describe the obvious. Name things well, and it’s suddenly very easy to become entrenched in the drama of these variables. Imagine a TV drama about your code called Variables: In Scope.

Writing clear, informative prose for others about your code is a part of writing good code. If you want to be a 10x developer, make other people’s development processes easier.

People Skills - Persuasion with Regards to Application Features

One aspect that was brought up a fair amount was how to get the client to make a real decision, and how to still make room for them wanting something else. How can you write code and perhaps more importantly actionable tickets against a fair understanding of where most of that uncertainty lies?

Be clear and intentional in your communications. Be adept at explaining, simplifying, summarizing issues in Slack and/or in pull request comments. Be civil and direct. Do not be too indirect. The aim is constantly open areas of uncertainty and expose them to light so that that uncertainty is extinguished and we can all move on with our lives and in the project as well onto other bugs and yet other features.

Establish a predictable style of communication with your team so that they can safely assume certain contexts of developer intent or purpose.

Have a good time with your coworkers! A generally good attitude and light take on things goes a very long way in making this into pleasant work.

Reviewing, Reiterating, and Moving On

If there are particular things that you liked about a project, make sure to take the time and distill the good parts as well as where and what you would like to optimize further. This way, you will have a very defined version of it for yourself apart from the project that it was gleaned from, that you can abstract as needed and make use of elsewhere.

This could be a certain snippet of code, a link or set of links to refer to for certain hard-to-find information, or a description of a a debugging story or feature persuasion tactic, or even just a chrome browser extension that is very useful.

As a developer, a core tenet of your life is looking and thinking critically about your aims and your environment, and taking intelligent steps to optimize each of those for maximum enjoyment.