The following are a few thoughts, mostly non-technical career-advice – things I learned in my previous roles as software developer, tech lead and architect.
Might be useful for some. Some might have heard/read/thought similar opinions before.
Learn basic principles
Don't learn abstractions or implementation-specifics – learn basics, principles and foundations! Don't learn Azure, or "the cloud" – learn systems, networks, ops and admin.
Similarly: don't learn to "program Java" – learn C-style syntax. And just like with human languages: the more languages you learn, the easier the next one will be. Not to mention how useful the exposure to different approaches (via differences in syntax and implementation) is for your comprehension.
Try to become aware of what you don't know – be it fields you aren't an expert in, technologies you have no experience with and opinions you don't understand. Don't hide the fact that you don't know, but appreciate this fact to build intellectual humility; Educate yourself by communicating with those that know or learning by yourself. Strive to actively seek new impulses, other perspectives, etc. – as in life in general: The more new ideas you can expose yourself to, the better.
Seek opportunities to work with other people, preferrably people that know something you don't on some level (be it specialization or profession).
For example, pair-programming lets you reason about problem solving while simultaneously having a different perspective available to you – a different mind thinking different thoughts will make different considerations than you, and potentially catch different problems.
Code-review ensures quality by way of getting another pair of eyes to look at your code, questioning your assumpitions – and it might even give you actionable feedback that not only makes the problem du jour solvable, but also lets you grow as a developer.
Consider Non-Functional Requirements
Functional requirements (requirements describing what the system should be able to do) is one thing, but in developing as a developer (...) you should start considering non-functional requirements as well.
Non-functional requirements (or NFRs) – also known as quality requirements – "specifies criteria that can be used to judge the operation of a system, rather than specific behaviors". Examples include accessibility, interoperability, security, privacy, stability, scalability, efficiency, and usability. These properties of the system as a whole can be just as important as functional requirements; The way in which a system does what it does will in many cases be just as (if not more) important as what functionality it implements for users.
NFRs are thus (arguably) more a consern in architecture than in pure systems design.
Just do it!
Though it can seem overwhelming: Dig deep and try stuff! Read specs, experiment with stuff that's out of your comfort zone and learn something new!
Learn to find the information you need. Get familiar with reading manuals (RTFM!) using
man <whatever command>, googling, and so on. Maybe look into Google Dorking – familiarize yourself with the Google Search operators.
Get comfortable with standard tools
Teach yourself *nix basics, and get comfortable in your shell of choice (typically bash, zsh or fish these days). You'd be amazed how many daily problems you can solve using only standard Unix command-line interface (CLI) progams in your terminal.
Take care of you body
Remember to take care of your body! Exercise every now and then, vary your sitting position, and take breaks for your eyes (look at something 20m away for 20 seconds every 20 minutes), back (stand up, don't hunch, engage your core) and mind (talk to someone about non-work, think about something else, do something meaningful and/or stimulating).
Learn about project structure
Take a look at popular open source software projects on GitHub, make a note of how they are organized – you'll learn a ton of best practices (documentation, README contents and structure, the importance of reproducibility in a development setup, testing-strategy, how to handle issues, and perform pull-requests and code-reviews)
Having your own side projects and contributing to open source can teach you a lot. It could be a good idea to doodle on software you find interesting (for whatever reason) every now and then – especially if it's something you're not particularly familiar with, or something that's different from what you usually work on.
On the other hand, it should not be expected that everyone spends their free time programming – people have different hobbies, after all... and it's not like we expect teachers to teach during their spare time, plumbers to plumb during their spare time, and so on.
Getting thrown onto an existing project's codebase can be challenging.
If it exists: seek out system design documents, diagrams of dataflows, and scripts that automate dev-setup. If these don't exist, take the opportunity to create them as you gain the knowledge yourself – you'll have to learn these things anyways, because you have to get up and running somehow. The other project participants will thank you, and the results will be invaluable the next time someone is to be onboarded (or when trying to reason about the system, if it is particularly complex).
Software design and architecture
- Simple code > clever code
- Maintainability, stability, and reproducibility are key
Re: Other people
I've noticed a certain type of people (spoiler alert: they're usually arrogant white guys), that will confidently start to blabber shallowly about how they can solve the problem at hand every time there's an issue, mostly using buzz-words, trends or dogma. When probed, it quickly becomes evident that they have definitely not understood the problem, the proposed solution, or generally though critically about the issue at all.
You've probably heard of the Dunning Kuger Effect – a cognitive bias that, at least in the west, is typically recognized by the inability of relatively incompetent people to recognize their own incompetence. They thus overestimate their own skill.
These people are said to be on "Mount Stupid", after the shape of the graph where the vertical axis represents confidence, and the horizontal axis represents Experience or Knowledge.
I'm not saying all low-skilled people over-estimate their abilities or vice versa, but there is a certain overlap, in my experience.
Many arrogant people will, generally speaking, have no idea what they're talking about.
"It's just a ride"
Technology's just a means to an end, a computer is just a tool.
Don't be dumb and make important technological decisions based on what's trendy, new or you'd like to work with. The goal of systems design and architecture is not to fluff your CV or to make sure you're having a great time – but to solve (business) problems using technology. That's it.
And definitely don't make an identity out of what tools you use at work.
Similarly, don't try to make your personal preferences mandatory for others.
Though every member of a team wants the shared code base to be "good", they have different opinions of what that entails. The importance of standardizing isn't necessarily in what standard you land on – indeed, the most important part is that there is a standard. Just compromise on a set of rules (linting and formatting included) that everyone can live with, and revise when needed.
Dogma, trends and hero-worship are, unfortunately, factors that affect technological choices more than they should.
Learn to reason; Realize what you don't know. Be intellectually humble. That doesn't mean you should entertain obviously bad ideas or not make suggestions, but realize that most alternatives have trade-offs and that it's unlikely that anyone knows everything (especially beforehand).
Bonus tip: When optimizing or comparing, you should measure (though identifying good metrics is an art unto itself).
Try to limit multitasking, as humans are usually very bad at this; Work on as few things as possible at any one time.
Seek to shorten feedback loops (time between planning and evaluating the same task); work in small increments, and verify & evaluate work as often as possible.
People, not processes
Finding a working process that works for you is more important than dogmatic adherence to rules.
This means no meetings for the sake of having meetings (or because "the rules" say so) – they should be needed, and help you achieve your goals. Supportive functions are not goals in and of themselves, after all.
Kind of a low-effort brain-dump – but hopefully useful for someone.