There’s an overwhelming universe of technical content to learn, but ignoring the world beyond that will be at your peril.
Commit to only to what you can get done.
Essentially, talk is cheap. And getting things done is hard. The issue here is that there is a huge difference between an idea and something that works, and then another huge difference between that and something people are actually using. Those differences are often because of the last 20% of a project, the last 20% can take the most time, and it’s usually the least interesting things that are left. The challenge isn’t in the nature of the remaining items, but more in keeping track and staying on top of them, which is a different skill set.
It can be easy to underestimate that last 20% and say you can get something done, letting people down because it takes more time than expcted to get the value of that project. I’ve also learnt to consider that the complexity of handling these details does not scale linearly as you begin to deal with multiple projects.
The skill of finishing things is worth learning though, there’s a lot of value in being someone who delivers and is trusted when they say they are going to get something done.
Understand the value of what you are making.
Eventually you will have to be able to answer the question “Why?”. “Why does this matter?”, “Why do it this way?”, “Why should I use this?”. The better you understand the value of what you are making the easier it’s going to be to answer those questions.
It’s worth noting that there’s a lot of room on this before you hit diminishing returns, the better you understand where the value is in the solution space the more you can prioritise what actually matters.
Experience has also led me to, strongly, believe that earlier is better than later. If you don’t understand the value of what you’re making you don’t know if you’re making the right thing, and that’s the sort of mistake you want to catch as soon as possible.
The job isn’t about coding as much as I thought it was.
Given a choice between a useful but poorly coded thing and something well coded but even just fractionally less useful the reality is people will go for the former most of the time; regardless of the implications of that decision. For a lot of projects the difference between bad and good enough isn’t code quality (or derivatives thereof such as bugs or speed) but timing, features, and the ecosystem the product fits within. You have to be able to balance the technical quality of a solution with the practicalities of the situation, that is not easy and it requires the composition of both a technical and non-technical skill set; either of which are hard to acquire individually.
Ultimately what I’ve learnt is that sometimes the code isn’t the hardest thing. Don’t neglect your non-technical skills, you can’t survive on code alone.
