Things I’ve learned in 20+ years as a software engineer.
You need a work laptop
Not only does this give you the option of working from home but in reality your brain doesn’t work 9-to-5. You can make a note of an idea for tomorrow but why not get it done there and then? If your employer gets two weeks of extra work out of you then it’s already paid for itself.
When you’re deep in the debug zone there’s no time for hunt and peckers. Curiously, senior engineers can be a little snooty about touch typing but anything that gets in the way of expressing yourself can only be a bad thing. You should be able to manage at least 50 wpm.
Eat your own dog food
Use the tools, OS and software you use/write to do a job – be it your actual day job or your home side projects – but aim to use your software as an end user. If you target Linux by day then you should be running Ubuntu at night; use Jira at work, then use Trello to manage your chores.
Don’t just study when somebody thinks you should go on a course. In my whole career I think only one formal training course has had any lasting impact (as it happens it was an introduction to Agile). See if you can convince somebody to pay for a Pluralsight subscription or at least make use of the free trial to pique your interest.
Develop in the debugger
There are times when you find yourself debugging with
cout but this should be a last resort: it’s incredibly slow and doesn’t give you anywhere near the insight of a proper debugger. If this is normal then you need to fix your dev environment. See gdbgui and some other Linux debuggers..
Get comfortable describing the complexity of your code.
Even if you don’t end up pushing to a repo like GitLab. It’s useful to have a lightweight config control tool only a
git init away.
Learn a fundamentally different language
Keep your head in the cloud
Register with a cloud provider, spin up a VM and compile things. Cloud computing isn’t going away and just doing this alone exercises a whole heap of excellent transferable skills.
Implement the basics and then optimise
Not my advice but something I’m still reminded of regularly. Sometimes a crude implementation is good enough and it will let you get a feel for your new feature’s worth before investing additional time. Is it better to accept a minor performance hit if the solution is more readable?
Programmers waste enormous amounts of time thinking about, or worrying about, the speed of noncritical parts of their programs, and these attempts at efficiency actually have a strong negative impact when debugging and maintenance are considered. We should forget about small efficiencies, say about 97% of the time: premature optimization is the root of all evil. Yet we should not pass up our opportunities in that critical 3%.