Or, more accurately, 10 things I learned about software that I wish I knew when I started. But that's not as catchy and didn't fit on the film poster so you'll have to indulge me and my love for cheesy films.
I've been in the software game for about 12 years by now, maybe a few more years if you count the early teen years of playing with Borland Delphi (which is rather strange now that I think of it) and even slightly longer if you want to count all the time having to write BASIC on my green screen Amstrad when I was an actual bairn. So by all accounts, I'm still rather early in my career and still have a million and one things left to learn and probably even more mistakes to make and pick myself up from. But I'm mid-30s now, my knees hurt and now I need to be in bed by 10 pm so I feel long enough in the tooth to offer some unsolicited advice to the internet.
I've had a varied time in the workplace; from one of the big consultancies to start-ups, government to games, junior to senior (whatever that means). These are ten of the things about working in tech that I've been gifted by people much wiser than me, or found out for myself through my journey that I wish I knew at the start.
1. Software is mostly about people
Machines run our code, but that's mostly beside the point; machines can't get annoyed with us and they certainly don't pay our wages, so it's people that we need to foster good relationships with.
The stereotypical engineer likes basements, coffee, arguing over Emacs vs Vim (that's old people VSCode for those of you under 30) and not talking to other humans. But, other humans are where we get our problem statements from, who we're delivering solutions for, who we craft the code with, etc. Making time in our day to forge and maintain relationships with colleagues and peers gives us a network of support and knowledge. We do our best work in teams, after all.
2. Converse more than you code
Insert overused Einstein quote here.
We're coders, so therefore we like to and are drawn to writing code. I think that one of the differentiators between an ok engineer and a great engineer is how they talk through and define the problem they're trying to solve. Talk to more people about it and you'll get more detail, more perspectives, more possible approaches and you'll cultivate a wider, shared understanding of the problem and solutions. The better you can talk about and define the problem, the easier and quicker it'll be to solve through code (or maybe you'll discover you don't need to write any!).
3. The job's not done just because "it works"
Getting something working is great; writing up a solution to a problem is so satisfying and probably the thing that most of us enjoy the most about the job. But it doesn't all stop there. Earlier on in my career, I missed out on the refactoring opportunities, learning how to tidy up the points where my code integrates with other peoples' or systems, all the different ways to approach testing etc. Even when all your tests pass, there might still be a few tweaks to your design you can make.
4. Life's full of contradictions; most of the time "it works" is good enough
Don't let perfect be the enemy of good; there absolutely comes a point where we should just move on to the next job/feature/story and sometimes it's easier to tell when that is than others. In the past I've spent far too long trying to get things slightly better where it wouldn't make much difference to the value to code was offering, it was only for myself. If there's time spare, this is a nice self indulgence but often we could have moved on to something else.
5. Be bold and break things
One way I learn is by breaking something and then having to fix it again. The sign-in flow, the schema migration, loads of stuff has been borked and deborked over the years. Hopefully, most breakages are caught by tests but those that aren't still teach you something about your test approach or the way code interacts with other code, and really, as long as they're all broken and fixed again in a local/dev environment; who cares? I'm not advocating for being a bit fast and loose with code and deployments, but if we're too scared about breaking things then we might not want to take a chance on a new library or pattern.
I remember getting lambasted in my first job when I did my first dev build and broke it three times in a row; all I learned there was to not offer to do the build again.
I still break builds from time to time, I used to care and now I don't.
6. Reading is good, but doing is better
I'm a serial course taker, blog and dev.to reader. I love reading about new patterns and tools I could use in my day to day. The bit I used to get stuck at was actually trying them out in projects, mostly because I wasn't sure the coding style would be cohesive or if it was really worth adding in another library dependency. But I can't overstate the value from just giving things a go and seeing how they work in your code context.
Try things out, see where the seams are and if it doesn't work out, the best thing about code is that you can rewrite it.
7. To hell with hierarchy
Larger companies tend to put more emphasis on team hierarchy than smaller ones, and a lot of the titles are sort of meaningless or at the very least only give a vague impression of differentiation. Senior engineer here might equate to an intermediate over there, for example. But increasingly, I really believe the titles are less important than having a variety of perspectives and experiences and a richness of knowledge follows from that.
Junior, intermediate, senior - who cares? Simply make friends with people you want to learn from
8. Assert(true).is(true); fake it till you make it
No one knows it all; we're just doing the best with what we know now and filling in the gaps, even the lead engineer who built the whole platform on their own over the long weekend. I'm not entirely convinced that the imposter syndrome a lot of us feel ever completely goes away, so I've certainly always felt like I'm faking it all to some degree but over the years you'll realise that the bits you fake get fewer and the bits you know multiply. So give yourself some space; playing pretend is fun, anyway!
9. Balance complexity with simplicity
I love fancy code, who doesn't like feeling a bit clever when they've written something smart looking? Would I still understand it if I came back a month later? If not, then it probably needs a rewrite, or I'll get annoyed at myself for writing something so incomprehensible. And my peers might not be best pleased either.
But everything is a bit complicated the first time you see it, don't let the desire for simplicity stop you from learning a helpful new abstraction that you might have to then teach others. Code simplicity doesn't mean reducing everything to if statements and for loops just because they're the language primitives.
10. Don't believe the marketecture
There's always going to be a time when you need to use a commercial tool or two and unavoidably you'll have to pick one amongst their competitors. Marketing material is easier to get to than technical documentation, especially for closed-source products. Invariably it will tell you a shiny and wonderful tale of how this particular product will solve all of your woes, is absolutely config free and has frictionless upgrades. Sounds great, but does it all stack up in reality?
Off-the-shelf tools can be great and can be the only practical solution to what you're working on, but do read around first. Community reviews or support boards are a good way to get a feel for the tool and how people end up using it to meet their needs and can offer invaluably candid opinions on things.
Top comments (0)