Opinions After 20 Years of Software Development
Inspired by other articles I've read about various developers' opinions on software.
These opinions formed along the way in my career that I wouldn't always agree with in the past, but that is called learning.
So here's my list in no particular order:
Have an open mind but also strong opinions: People gather into tribes/camps on everything, like tabs vs. spaces, JS vs. TS, etc. Having an open mind to new things is essential, but also strong opinions on things you know it's working, otherwise you will just drift with the flow.
There are no terrible programming languages: They were created to solve problems, if you haven't faced that problem it doesn't automatically mean they are bad, it's just not the right one for your particular problem.
No such thing as right or wrong software: only more or less fitting to the problem context.
Context switching does more damage than it seems: Let developers develop. If you constantly interrupt them they will be much less performant. This includes setting up calls for every insignificant problem just to have a "face-to-face". 90% of things could be an e-mail or a Slack message.
Clients will lose focus on the bigger picture: If the project is complex, there will come a time when those client calls are just bikeshedding that will waste everybody's time.
Not everything is about work: even if you love what you do, you must set up a healthy work-life balance. I love what I do with a passion, but I rarely do work stuff after 5 PM.
Technologies change: I tell every dev I work with, to learn the general programming principles and they will be fine for the rest of their life. If you learn technologies instead of programming you will become obsolete when, and not if, that technology falls out of trend. 10 years ago my tech. stack looked totally different than today and in the next 10 years, I'm sure it will look radically different.
No FOMO: It's nice to play with new technologies, but don't base your career on FOMO, like AI is the shiny new thing now, I do use it, and I play around with it, but I'm not jumping in head-first replacing my tech stack and approach to programming.
Cross the bridge when you get there: Don't write code toward inexistent scenarios. "What ifs" will miss the deadline every time.
Code is the by-product of programming: Software development is so much more than writing code, learn the other aspects of it. This is why metrics like LoC are useless and an anti-pattern. In my experience, writing code is 20% of the overall work that needs to be done.
It's human nature to be lazy: A task will always fill out the time that is assigned to it. Lazy programming and coding practices should be nipped in the bud early on with a rather firm stance.
Becoming bored is the leading cause of leaving a company: when there's no end-sight to a task or a feature communications break down and boredom settles in. At first, devs. will go on auto-pilot and then switch jobs.
Boring and simple is always the right answer: I would rather work with boring and simple technologies or projects than the new shiny things that don't get the job done or projects that will fade out of relevance very quickly.
Tooling is important: Good tools that help you and other devs are important. If it's complicated to set up, nobody will use it.
The more communication "choke points" the worse is the result: If you can talk directly to somebody then do it. The more people in the communication chain the more problems and misunderstandings. It's like the game of Telephone.
It's a fine balance when asking for help: What I want to hear from a dev is that they exhausted every possible avenue and can't move ahead, and only then ask for help. It's a fine balance because devs could shy away very quickly from asking for help but also it's not productive to hold their hands on every minuscule thing.
Bet on the human: Treat devs as humans and not "resources" and it will pay off in the long run.
Technical interviews are almost useless: Nobody can assess technical skills in this industry by doing 1 - 2 rounds of interviews. You could only have "some" idea. I would rather hire the individual with a paid internship for a couple of months to see if they are a good team fit, and this is also true from the developer's perspective. If the expectations are set upfront it's a win-win for everybody and there are no hard feelings if things don't align.
Processes are not important at the beginning: only when you grow bigger do they become essential.
Junior devs will not be productive right away: Depending on the onboarding processes, junior devs will need a couple of weeks to a few months before they can become productive on a project or team.
The world is built on open source: and it's hanging by a thin thread, that if breaks, will burn down this whole circus.
