This article is a response to the excellent question by @Nellies.
This lifelong learning thing, is there any talk on how to deal with the infinite amount of stuff there is to learn?
I do ok, but sometimes the todo list does get cumbersome.
Is that part of the whole burnout in tech? No worries, I have broad shoulders, just curious.
Most of my examples are going to biased towards full stack or frontend web development, since that’s where I have the most familiarity. This is also written to people trying to break into software development, or just want to understand what it’s like to manage this aspect of a software development career. I also gloss over a lot of things, especially cultural factors that make software development harder for those who can’t pass as white males.
As mentioned by Nellie, one of the aspects of software development is that software developers are expected to constantly be learning new things. Or, at least, that’s the impression that happens from the outside. There are some mitigating factors, however.
The first is that once you learn the fundamentals for a particular technology stack, moving between similar flavors of that stack is made much easier. Once you understand the fundamentals of HTTP, HTML, CSS and JS, picking up Rails, Django or ASP.NET becomes much easier.
The second is varying types of knowledge have different shelf-lives. The cool new shiny JS framework being promoted by its creator? That could be relevant for only 6 months, or it could be the next React. It can be hard to tell up front, especially when you’re new. Thankfully, most jobs also lag the hotness by a certain amount, not everything asks for the hottest new tech.
But, if you’re learning HTTP status codes, or headers and auth works? That knowledge stays relevant a lot longer, and is part of all web apps. As a bonus, learning more fundamental knowledge gives you an edge when it comes to debugging problems, which is one thing that can help you stand out in your early years. Also, different types of knowledge have different acquisition costs. Basic JS or HTML is relatively easy compared to writing a full stack web app, which is easier than building a reasonably full scripting language, which, in turn, is easier than building a production grade data store like Postgresql or MongoDB.
Another factor is that it’s possible to specialize inside a given stack. So, for instance, with Rails, if you hit an area where your co-workers don’t seem to know a lot, that’s a good place to start a deep dive into how it works. Because then you’ll be able to build a reputation as the person who can figure out tricky things. You don’t have to know the whole stack at that same level of detail. If you’re known as “The ActiveRecord Bender” or “The Database Index Guru” or “The CSS Animations Witch”, people will give you more credit when you ask for help in their area of expertise. This also synergizes with learning fundamentals, and is where fundamentals can help you out.
There are some trade-offs in play here. The first is that most foundational knowledge doesn’t show up as keywords on a resume, and most companies are poor at assessing it (to my knowledge). Either they assume that you have it if you have relevant keywords, or that you can pick up (or have) foundational as you go, or they pattern match you during the interview against what they expect people to know for the job. And nobody has time to learn everything all at once, no, not even that super impressive open source developer or Indie game development.
So, don’t learn everything all at once. You will have to look a lot of things up during your day to day work, even after a decade in the field. But, especially in your early years, do make time to learn things. Jobs for junior candidates will expect you spend a lot of time learning things. If they don’t they shouldn’t have hired you for that level. Any programming job involves learning the companies code base for at least the first 2-6 months you’re on a project, unless they follow a very conventional structure. So take advantage of the junior position and learn your job’s tech stack as effectively as you can.
Be sure to take deep dives into the tech involved at your first position, trying to understand one layer deeper than the one you’re working at. This doesn’t have to happen every ticket, but it should be happening at least once every paycheck or two. Often the lower layers are simpler than you might think, or make understanding the higher levels a lot easier. Understanding the lower levels also gives you a much better nose for when code is fluff vs substance. This guides your debugging, grows your fundamentals, and speeds up future work.
When you are in your early years, you will need to front-load learning the basics. Unless you have some other skill set that can get you into the tech industry (there are a few, Quality Assurance/Testing comes to mind, as does being an engineer in a more continuous field, like aerospace, materials design, or the like), this is going to have to come out of your own time. Bootcamps are good for getting resume keywords under your belt, though they typically don’t spend much time on fundamentals. Colleges focus a lot more on fundamentals, but might use tech 5-20 year out of date. Either one will require you to figure out how to fill the gaps left by it.
For me, I had the luck to be able to carve out school time in high school (I was home schooled) on Fridays for morning each week to work through Head First C#. At the same time, I had an aspirational project to build a Scientific Calculator GUI app, which was solidly outside what I could pull off with what I started out knowing. For the first year or two, especially before you get a job, I’d recommend setting aside a time box in a similar fashion. If life doesn’t afford that timebox, then you’ll have to be a lot more proactive about making time.
Also, don’t try to code in a void, sit down with a game plan of what you’re going to try to do or learn. If you get to your time, and you don’t have that, take a walk and think about it, or do a chore with the plan in the back of your head. Often problems are solved away from the screen, or in conversations with [ducks][rubberducking] or teddy bears. Tunnel vision is a dangerous trap in software development
Once you have your first job (or two), and have established your base knowledge, then the question comes up of how to maintain the learning required to keep up with tech. And this ultimately depends on what you plan do to with your career. If software is a stepping stone that takes you on to the next thing, then you can afford to burn a lot more of your motivation and time, and focus where the market is hot, and try to get 3-5 jobs out of that, setting yourself up as much for the next step as you can.
If you’re wanting to stay in software for the long haul, then I’d recommend a different approach from chasing the hype. Try to find the fun in software development. And, as you learn how to find the fun in building and learning things, be sure to pace yourself. I’ve had 6-week stretches of working hard at learning a new language, ecosystem, or side-project, followed by months of focusing on other things.
You don’t have to learn at 100% every week once you feel comfortable in your ability to build projects of a small-medium size. For web development, this would probably be about the point you’re able to write your own blogging software, for whatever functionality you’re looking for. You should be learning new things on a semi-regular basis. But keep it sustainable. One thing that really helps here is to have a process for documenting what you’ve learned, in some fashion. I’ve biased towards publishing code in the past, because that’s what’s been easiest for me.
Don’t use side projects as your only tool for learning software. I used to think this was the best way to learn, because it was how I had learned a lot of things. It has disadvantages, however. For one, side projects that are actually useful are more time-consuming than something you can throw away, and the kernel of what you’re learning might be discoverable in the shorter exercise. Noah Gibbs has a lot more to say here, and I owe a lot to his writing and companionship for changing how I approach learning in the last year.
But, whether through side projects, blogging, or building a portfolio, I do think that finding a way to publish your learnings is valuable. The nice thing about publishing and shipping smaller things on the side is that you do end up building a signal to employers that you have “passion”. This also allows you to ratchet your perceived learnings more sustainably than always trying to be at 100% learning mode.
The main time I think that it’s worth going a highly regular output (like, once a week or more often) on the side is if you are aiming to become a proper software development celebrity. This is not for everyone, and likely doesn’t pay as well as you’d think, unless you spend a lot of time figuring out how to get it to do so, and you’re magically successful with it. There’s also a whole host of Not Writing Code that goes into making money off of it.
Doing this for a season, akin to an art challenge, is a great way to learn a lot in a short time, if you have the time and energy. If you’re looking to make a lot of money on the side, however, freelancing is likely a better bet, once you have the skillset to pull that off. As much as selling your hours for money isn’t the path to higher wealth bands, it’s a much less risky tradeoff compared to product development or trying to build a personal brand.
Try to find the fun, as well as a sustainable long-term motivation. Look for trade-offs rather than dogma. Use binary search debugging. Listen to your body, and be honest with yourself.
[rubberducking]:https://rubberduckdebugging.com/