On Learning Fundamentals

Programmers are buzzword-driven people. Programmers strive towards buzzwords as mosquitos strive towards light or flies towards shit. I am a programmer, so I suffer from the same disease, but try hard to resist. Let me elaborate.

The problem with buzzwords is that they are dangerous. Buzzwords come and go, so your skills. Learning is investment. Is it reasonable to invest in something that will make you naked soon, make your skills needless, impermanent? Probably not. As any investment, learning requires careful planning. Planning for future.

That’s why we have to spend most of our time on learning fundamentals. As in civil engineering, fundament is the core of everything. You can’t build on top of broken fundament. Fundament must be rock-solid. Your fundamental skills must be rock-solid too.

Catchy job ads, employers looking for “Big Data” guys, headhunters asking for fancy CV, ThoughtWorks radars, conference talks— everything will try to throw you off the road. Resist. Don’t be trapped by bright, but deceptive lights.

I don’t want to say that keeping up with trends is not important. I am talking about setting the right priorities. Fundamentals come first, furnishing last.

A client of mine once mentioned that they have hired a developer just because he had experience with particular framework. Why? They feared of hiring someone unfamiliar with the technology because the candidate will start re-inventing a wheel.

Let’s imagine Android was the target technology. I agree, Android is tough nut. It has its own tips & tricks and Android experience is of high demand today. Now imagine there are two candidates — a shitty-Android-coder & a craftsman without hands-on Android experience. I would bet on craftsman. Why? Because shitty coder will not even know how to re-invent the wheel.

I have a bunch of presentations shared on SlideShare touching broad range of IT topics — Continuous Delivery, Micro Services, SOLID etc. Guess which topics got more attention? Catchy ones! No one cares about SOLID, despite it’s a set of fundamental OO practices. SOLID is not modern. SOLID will not make your LinkedIn profile attractive. Yet grasping SOLID will make you a better programmer. I’d even say that lack of SOLID knowledge will make you a defective programmer, as any building with broken fundament is defective. Will I surprise you by saying that the whole idea of micro services is based on some of the SOLID principles? Don’t look away. Fundamentals came first.

What are these fundamentals?

As a programmer we spend our time writing code, so we have to learn how to produce effective and maintainable code. Hence clean code. Learning a set of patterns and best-practices is not enough. We must learn how to reason about code, understand rationality behind every pattern & idiom. This way we will make our knowledge long-living, portable among platforms, independent from temporal fashion, but still extremely usable. Ability to perform high-grade Object-Oriented Analysis & Design is vital. You can claim OO is not trendy anymore and functional programming will rule the world by throwing OO overboard, so let it be. I don’t think I will live to see this happen☺. OO is dominating whether you want it or not. OO is not easy. OO deserves significantly more attention than it’s given nowadays. It’s pity to see that we haven’t learned much about OO since 196* and still produce stupid things like classes with deep inheritance trees, re-use by inheritance, long train wrecks etc.

Ability to work effectively with legacy, usually shitty code should not be underestimated. That’s because big-rewrites are neither negotiable nor reasonable. Developers must accept that sooner or later every application will become legacy. You can jump from project to project, change companies, run startup, but all roads lead to legacy. Since you can’t change it, it’s important to learn how to ride legacy software with smile on your face.

Domain-Driven-Design is forgotten kryptonite. Mind-changing. Mind-blowing. Eye-opening. If someone told me about DDD earlier… I would never produce that crappy model for Debt Collection software…

Test-Driven-Development is still seen as a magic ball in the hands of wizards. Wizards that magically produce better code. There is no magic, better code comes from adhering to a set of TDD disciplines. Beware TDD is 15 years old & adding it to your LinkedIn’s skill-set can make your look too conservative…

Of course there is much more to learn. But by tackling aforementioned techniques, you’ll accelerate your further learning process by seeing connection between dots that are invisible for everyone else. Puzzle pieces somehow will come together. That’s the path towards craftsmanship.

Don’t rush. You can read myriads of books, however it’s just a waste of your precious time. Remember that the secret hides in understanding. Learn slowly, follow the author’s thinking, write things down so to get back to the records in future.

And the last thing — you may misunderstand me by starting diving into low-level programming, JVM internals, Linux kernel etc. Please don’t, until you’re system programmer. It’s still very specific, niche knowledge. Niche fundamentals are important, but not as important as general fundamentals. General fundamentals first, niche fundamentals last.

Additions to your bookshelf

I’ll list some books that I think every developer must read. I hope they’ll appear on your bookshelf soon. You can watch my Shelfari account, I keep reading list up-to-date and mark must-read books with 5 stars.

The Pragmatic Programmer: From Journeyman to Master

Clean Code

Clean Coder

Coding: On Software Design Process

Growing Object-Oriented Software Guided By Tests

Domain-Driven-Design

Please share this article if you liked it and don't forget to follow me on Twitter. Ah, don't be shy to comment ↓ as well!