22 Valuable Lessons From Decade of Software Engineering

Almost 3 decades of professional experience broadly agrees with you, except:

2. The tech world moves quickly. Make learning a habit

...but learn to see through BS and don't blindly follow the latest trends - learn about what interests you.

9. Your time estimations will be way off. Underpromise and over-deliver

Don't do estimates, they are a total waste of time.

11. Career growth without acquiring soft skills can be hard

Be careful what you wish for, some career 'growth' can take you further and further away from what (presumably) you loved about development in the first place. There's more to growth than fancy job titles and (hopefully) more money.

13. Learn googling. You don’t need to build what you can search for

It's often better to google concepts and implement something small yourself, rather than import a whole library or blindly import some code without understanding it. Your code will be less bloated, and building it yourself will teach you more. Learning how to use Google well is very beneficial though (search modifiers etc.)

17. You can only improve what you measure

Not really true. Some improvements are subjective and impossible to measure. Totally depends on the type of project, the audience (if it has one), goals etc.

19. A good portfolio brings contacts, clients and potential employers

Possibly, but generally (unless it is really unique and exceptional - which most aren't) I've found that portfolio sites are entirely unnecessary - just focus on building cool stuff on GitHub/GitLab/whatever - this is a more honest representation of your skills and development/coding interests than any curated vanity project could ever be.

21. You learn by finishing projects, not by starting them.

Not true at all in my experience. You learn way more from all the false starts, failures, and experiments that never made the finish line (if indeed there was a such a line, which for most projects - there isn't)

Very helpful tips Void! 👏🏻👏🏻

So many good stuff here!
My faves:
You don’t need more courses. You need to build projects.
Doing tutorials hide knowledge gaps. Building projects expose them.
Learn googling. You don’t need to build what you can search for.

And even though I feel called out by this one I still like it
You learn by finishing projects, not by starting them.

Learn googling. You don’t need to build what you can search for.

Google is fine until you get back: 0 results returned and there are no suggestions.

That's when I know I've either misspelled something OR I've entered a completely esoteric area of software development that no one has ever explored. I know I am probably on my own at that point. Every 6 months or so this will happen to me. I then start measuring how many browser tabs I have open, which is a pretty good metric of topic complexity.

Oddly, Googlebot doesn't seem to search GitHub source code and also seems to miss a lot of StackExchange/StackOverflow posts. Running the same search on those search engines sometimes turns up hundreds or thousands of results when Google returns nothing. Also, starting to type up a question on SO/SE sometimes turns up results that their own search engines missed earlier. The current search engine fragmentation makes me wonder if Google employees are even able find important, authoritative information. Of course, when I get back nothing in all of the search engines, then I have some level of confidence that I've reached the current limit of human knowledge. This only happens to me once every 2-3 years. The question then becomes: Do I pursue it knowing it might be up to six months before I surface again? Running a cost-benefit/ROI analysis can be useful to avoid unnecessary pain.

Mostly agree with Jon, except "estimates are a waste of time", precise estimation in complex endeavours is a waste of time because you just don't know at the start of a project. Unless you are doing the exact same thing over and over again (in which are you really in the right job?), your estimates will be off. And that's ok! It's an estimate, not a promise! And you need to challenge your PO/manager if they desire precision.

Which brings me to a couple of things that I'd like to add:

• Dont just try to learn everything preemptively or speculatively, it wont stick until you actually work on a real problem that benefits from that tech

• Get into the habit of writing your thoughts down: notes, blog posts whatever. Nothing surfaces the loop holes in your thinking faster.

• "Learn to speak in business terns". I cannot stress enough how important this is to actually getting critical engineering work done or think about the work critically. Your super amazing tech idea is no good if it gets put on the backburner or your manager/PO wont sponsor it. This means learning to understand the economics of software engineering. What's the work? What's the cost (estimate)? What's the value/ROI (return on investment)? To the business, these numbers make more sense than "cyclomatic complexity" or "tight coupling" or what have you! So if you can adjust your message for the business audience in terms they can relate to, you become that much more valuable because you are helping put your and your team's technical vision on the product roadmap.

Be under no illusion, this is going to be HARD but after nearly 20 years working in this industry, I wish someone had told me to focus on these things or I had paid more attention to it back then.

• "learn the business". Understand how your company makes money and how it makes decisions. Spend time learning the business domain you are working in, it's going to be infinitely more valuable than learning the fanciest new frontend framework or programming paradigm or cloud thing. Tech serves a purpose of solving real problems, don't make tech a goal in itself.

I recommended creating a system around your daily life that improves goal consistency. You'll get the best of yourself through exponential growth. You'll run slow in the beginning, but faster in the end.

A lot of good advice

Thanks

Thanks for sharing @codewithvoid

Very helpful!

Nice tips :)