A good friend of mine is interested in changing careers to become a software developer, and naturally I’m trying to find ways to help him with that transition. He’s dabbled in software for a long time, writing applications for himself and others to use, in a variety of different languages. However, in order to land a full time developer job at a level he’d be comfortable, he’s asked me what skills/knowledge gaps he has, and what he should do about this – “should I learn ___ framework?” “what about ___ language?” and so on. The answer, as always, is “it depends”.
For an absolute newcomer to software development, the first thing everyone has to learn is a technology. Without this, there is no context to apply anything else to, besides software development is about building and without learning a language or technology, it’s impossible to build anything. At this stage, it doesn’t actually matter which language, but things like JavaScript are very accessible and hackable, or strongly typed languages like Java or C# can introduce concepts gently but allow for a lot of growth. Starting from nothing, the first learning goal is to be able to build something. Of course, it’s impossible to build something with no technique at all, but there is actually a lot of value in letting a beginner work some of this out for themselves rather than introducing techniques as taught or learned concepts. It’s important for people to try things and make mistakes, as part of forming their own mental models about how things work.
Once a developer is comfortable with at least one technology and able to build things, the value is now in learning techniques. While learning their first technology, a beginner will do things that will just about work, but that could be done much better. If they are to work on larger projects, or in a team, there are techniques that are needed to try to keep the growth of the project healthy. These techniques can be applied to a technology, but they are bigger than that and can be applied to many different technologies. A great technique to learn early on is how to write tests against software – ideally by learning the Test Driven Design discipline. The technique of TDD can be applied to most languages, and will change the way the learner thinks about building software. Another set of techniques that are worth learning early on are those around workflow, particularly in a team. This might mean learning about agile methodologies, or about version control workflows. Learning these techniques makes it easier to work as part of a software team.
After this point, developers should be continuously learning both technologies and techniques – it’s a fast-changing industry. Most individuals will realize before long that they have a personal preference for one or the other, and will be naturally inclined to pursue that more. Beyond that they may choose to go deep in a small number of areas and specialize, or to gain a broad knowledge of many. I think there is a lot to be gained from investigating a wide range of things, both to know what’s out there and have a better choice of what to specialize in, and to look for paradigms that can give benefits in other areas. I tend to lean towards techniques over technologies, because I find that having a strong knowledge of techniques means that I can apply these across many technologies and learn technologies relatively easily. In many cases, new technologies represent a new syntax on top of familiar paradigms.
When it comes to learning techniques, my main resources are reading and watching presentations. For learning technologies, the best way is by practice. I like to work with small “toy projects” that have relatively little functionality but that allow me to experiment with the technology. I’ve recently been learning F#, a functional language in the .Net ecosystem, and using the examples from Project Euler, a set of mathematical puzzles, as my problem domain. If I were learning something like a client development library (such as Angular, React etc), I might build a small user interface. I try to isolate the area I’m interested in, spending only minimal time on anything else. My F# Project Euler solutions are all about an algorithm, so I simply run them as scripts; when focusing on user interface I might knock together a very basic server to get going, but I’m not interested in writing complex logic or structuring the server any particular way because I can do that as a separate exercise. Having a single goal for these practice projects means I get the most from the time I spend on them, rather than spending all my time on the same things again and again.
For my friend in particular, my recommendation to him is that he focus on techniques for now. He knows enough technologies to build something, and actually is fairly adept at learning new syntax, which makes him able to learn a new language as part of joining a software team. However, as he is self-taught, he currently has large knowledge gaps around techniques. Because of this, if I were recruiting him, I would have to see him as a junior in the team, who is able to write code and get things done but who will need a lot of help from his team-mates to make that code be maintainable. Specifically for him, I would point him towards learning TDD, and the SOLID design principles, to help him gain an appreciation of how to separate concerns and structure components. Armed with these techniques, applied to the technologies he already knows will be enough to get started as a developer – and far more valuable than adding languages and frameworks.
One way to look at this is that techniques will help with deeper understanding, which leads to more mature ways of thinking about a problem, and help with “seniority” as a developer. A focus on techniques helps to reduce the complexity of solutions, and increase quality. However, the market is often driven by technologies. Selecting the right technologies to learn first will make a big difference to how easy or hard it is to find a first job as a developer; you are looking to learn technologies that are in demand. Right now, learning JavaScript is a good idea, probably in conjunction with a client-side framework (perhaps React), and it would make sense to learn to use JavaScript on the server as well (Node.js). As the market changes, all developers need to roll with the market, or they will have a hard time finding projects to fit skills that are no longer in demand. There are of course counter-examples to this; such as specialists in very old technologies, which are still used in some large organizations, where there is a lot of demand for the small number of specialists who maintain these.