Based on my own experience and interactions with many other developers, I'm going on the record with a possibly controversial opinion:
If you're a dev, especially one in the first five years of your career, you should be spending at least 10% of your on the clock time—at least 4 hours of your 40 hour work week—studying the fundamentals of programming. Put aside your assigned work for those 4 hours. Schedule them in your work calendar. Mark yourself unavailable on Slack. No matter how busy you are, protect that time.
Everybody wins here. The time you spend improving your fundamental skills will pay itself off almost immediately, then yield continuing returns for the rest of your career.
Why is this controversial? Because many developers would say it should be 25%.
To clarify, I'm not talking about "just-in-time" learning (looking up the APIs and patterns you need to finish a task at work). I'm talking about focused, academic, non-urgent study. Books, tutorials, courses, videos. Stuff that you could survive without, maybe indefinitely. Stuff that will help you swim instead of just treading water.
What are the fundamentals of programming?
For the programming language(s) you specialize in:
- Syntax
- Standard library
- Best practices
- Variable scope and lifetime
- Memory management
- Asynchrony, scheduling, threading, and concurrency
- Compilation toolchain
- Code navigation & IDE features
- Automated testing
- Debugging
- Top 10 packages
For programming in general:
- Data structures
- Big O notation
- Design patterns
- Software planning and architecture
- Quality assurance
- Functional programming concepts
- Recursion
- Information hiding/encapsulation
- Continuous integration/continuous delivery
- Threat modeling
- UX and user behavior
- Documentation
- Test-driven and interface-driven development
I'm sure I missed a few. Comments are open for additions/corrections.
Top comments (7)
Good article! Some companies need to do better supporting devs. For example offering additional training, certifications, or conferences for the developers who want to expand their skill set. Companies who support their developers will do better than the companies that don't.
Learning is forever.
I agree 100% with learning on company time, but I suspect there's a better way than books, tutorials, courses, and videos.
I've talked to a lot of people over the years who have read the books and done the tutorials and courses. The most common problem they run into is that they finish all of that and then they say "What now?" The content they're consuming doesn't prepare them for the crux of being a developer: figuring out how to solve problems. And I think that makes sense. Interesting problems can't be turned into a series of steps without losing the complexity that makes them interesting in the first place.
Another approach to learning on company time is for managers and senior engineers to create opportunities for less experienced engineers to stretch themselves on real work.
Let's take a couple of the things you listed as examples:
Asynchrony, scheduling, threading, and concurrency
I worked on this codebase where we had a high-volume job that was single-threaded across the entire cluster. Out of 250 machines only one could run a single instance of this job at a time. Eventually the backlog of events the job was meant to consume got so backed up that some of the events had latencies over 30 minutes. The latency should be less than one second.
Now I know how to solve this problem because I've run into it before. But let's assume there is a less experienced engineer on my team who has expressed interest in learning more about concurrent programming. This is a great opportunity for learning. They'll need to learn what options their language has for concurrent programming and what sorts of failure conditions they should expect. They'll have to come up with multiple possible solutions and then compare and contrast them before deciding on the one they want to implement. They'll inevitably run into bugs that simply aren't covered in any tutorial on concurrency and they'll learn how to identify, debug, and fix them. And I'm right there with them the entire way to provide as much or as little support and structure as they need.
Threat modeling
One time I joined a company and found multiple security bugs in the first week as I was just poking around the code. It was pretty alarming that I found them so easily and so I suggested to my boss that a good way to familiarize myself with the system would be to do a semi-thorough security audit. Could I have done this myself? Absolutely. But instead I found another engineer that was interested in learning more about security and we did the work together.
For starters, I suggested they do a quick read of the OWASP top ten to get a feel for the kinds of stuff we're going to look for. The bugs I found were related to improperly handling user input, so we started there. They were able to navigate the code and I helped them identify bugs by simply telling them "there is a bug in this endpoint" and then answering their questions as they debugged. After we found the bugs we worked together to come up with solutions. The other engineer drove the conversation and I was just along for the ride to support their learning however they needed.
I believe the engineers in both of these stories learned much more from these limited, real-world projects than they could learn from any book or tutorial. Books and tutorials are great for mapping out a topic: understanding the vocabulary, the common problems and bounds of the topic, etc. But past that you have to do real work.
This is a really fair and thoughtful response. I would agree that it’s important to give junior engineers plenty of opportunities at bat to solve any problems they’re interested in or currently learning about. But just like study is no replacement for practical experience, practical experience is far more powerful when paired with study.
Typically I find that juniors are inundated with problems to solve and opportunities to prove themselves. It’s often overwhelming. Regularly setting aside time to study can help them gain a foothold and understand the way forward, rather than just scrambling to keep up.
Great article. I am a firm believer that learning is part of the job. In some companies, we had a minimum learning time required for every job role.
I'd throw into the mix some soft skills, they are a key property of a good developer.
Fully agree and something I used to do more of. Trying to get back into it!
I agree and often did this when I was a junior.
If you work in a software company with flex time, often it won't matter anyway because you're putting in overtime and they don't care as long as you meet your commitments.
But I often found myself working with new technology so deepening my knowledge in stuff was very important to become an effective developer.
Right on point.
It is extremely important.
As navigating forward, the basics become blurry.
We may not feel it but we lag behind until we go back to the basics.
Great article =)
Basics should always be strong. Maybe for someone who loves teaching should give weekend classes as pro-bono to step up the people in the community which could prove to be a win-win for both parties.