For a developer, deciding what to invest time and effort on learning is difficult. This week, we asked the team how they prioritise skills to spend time on.
Kriszta Matyi, Senior Developer
I tend to prioritise what I learn about based on my needs at work. If I'm working on a node project and it uses MongoDB, I will take some personal time to learn about it. Similarly, if the project uses a new to me tool, say webpack, I will learn about that. I want the things I spend time learning about to be useful for me in a professional setting.
I'm also greatly influenced by what my friends and people I look up to in the industry are using/learning (looking at you React). If I see a lot of my friends using a particular technology I will be more tempted to learn it.
I will also look at the community for a technology, e.g. how welcoming they are, how diverse it is, the conferences they run (and what experiences people had at them), and whether there is a diversity and inclusion initiative attached to the community.
On a more general level I tend to prioritise learning languages over frameworks or platforms. I think these are best learned when on a project or client work, as opposed to in the abstract so I tend to learn these on the job as I need them.
In the past I used to have a very scattered learning plan. Nowadays I try to learn things that build on my current knowledge and complement it. For example, even though I'm tempted by the great community and the rising popularity of Python, I would prioritise learning Go first as that's the language I see most Ruby developers moving to.
Dorothy Wingrove, Senior Developer
Prioritising my learning is not something I'm highly skilled at. If I'm going to be using a new technology/language for a project I'll do some prep in order to hit the ground running.
I do like to explore new languages and frameworks when I can, even if just a shallow reading. I find this can keep me up to date and have context as to what is going on within the tech community. Picking what to explore is usually simply done on what people are talking about and using a lot. There's often a reason people are discussing it - good or bad. So I'll either be enlightened or entertained.
However, the way in which I learn a subject on a deeper level - once I've decided it's a topic worth really knowing - is by aiming to build something with it or use it in a side project, rather than reading a book about it. I think books and blog posts are incredibly helpful but I only find I retain the knowledge if I have had to use it to solve a problem I'm facing. That way I find I get much better (and longer lasting!) knowledge of the topic.
There's always a lot of change and lot of new possible things to learn. I'm trying to narrow down what I learn and focus of things I know I enjoy most. I think this may the only way I'll be able to keep my learning interesting, relevant and not too simplistic.
Najaf Ali, Founder
I’m no longer a full-time programmer, so my answer here will reflect that.
I’m a very slow learner, it takes a long time for me to get to the point where I feel comfortable charging for my abilities in a given domain. So I try to be careful when considering what technologies to invest my learning time into next.
When learning a new skill, I ideally want at least twenty years of utility out of it. A good rule of thumb for that has been whether that tool or skill-set is at least twenty years old. So for example, the unix command line, vim, and relational databases are tools that pass this test, and so any time spent with them is likely to have positive returns.
Another good gauge of whether a new thing is worth my time is looking at what my friends who are sensible experienced developers are saying. I’ve heard lot’s of good things about Go for example, so I’ll be amenable to learning that. I’ve never heard a good story about MongoDB on the other hand, so I’m probably never going to try it.
I’ll also look at the technical merits. Rust for example promises C-like performance or better, without garbage collection (and instead has a bunch of compile-time checks), pattern matching, and a type system. All of that in one language sounds genuinely useful, so I’d be OK with putting more time into Rust. Git at the time it came out was another seemingly obvious choice on its technical merits.
I’ll also look at who owns/sponsors a particular technology, tending towards open source but not religiously so. But if the owner of the technology is an unrelentingly evil big enterprise software company then I probably won’t put time into learning their stack. This is part of the reason I never learned anything on the Microsoft stack, for example. This is more because they can obsolete your skills overnight than for any moral reason.
Kaitlyn Tierney, Apprentice Developer
I have an incredibly long list of topics I'd like to learn about, and I add new things to the list on a near-daily basis. I have a list of places to find coding exercises, a massive Instapaper queue, and usually at least a few tabs open with docs I need to review or blog posts I'd like to skim over. I also have a list of books to read, a book or two on my desk, a few books on my bedside table, and a larger stack of books on the shelf next to my desk.
I really enjoy reading technical books. I learned HTML and CSS from reading source code back in the early internet days, but I learned the basics of programming from a coding boot camp just last year. My degrees are in literature—with a brief foray into fine arts in the middle—and library science. In a lot of ways, I feel as though I'm missing foundational computer science knowledge. The gnawing feeling that I need to make up for lost time is hard to shake, but it keeps me motivated.
Plus, I just really like the cadence of reading books. I like the detailed explanations and references for further reading, mentally anchoring concepts within a larger theoretical landscape.
Lately I've been reading through The Rails 4 Way. The cursory practice of a bootcamp, combined with the ad-hoc nature of tasks for clients, means that I still feel a bit shaky on the finer points of everything Rails does, and why things are designed the way they are. So far, this book is really helping me with that. Because I work with Rails on a daily basis, the code snippets and examples are all vaguely familiar, but every couple of sentences I'll read something and feel that sensation of things tying together in my mind.
Reading books feels like a I'm eyeing up a fistful of frustrating blue-and-white puzzle pieces, and before I know what's happening they've been assembled into a fluffy cloud in the corner, connecting up with other bits of the puzzle. The whole landscape of software development is coming together for me, slowly, and in a terrifyingly unordered fashion, but at least the uncertainty keeps me on my toes.
Gabriel Hilal, Senior Developer
I've worked in different fields before moving to the world of web development, from gardener to network technician, including electrician, cleaner, bartender, stocktaker, AutoCAD designer, system administrator, among other professions. In the majority of these occupations, the learning process was quite straightforward: there were standards, rules, and procedures to learn and follow.
However, when I decided to move to web development I didn't know where to start. Different from the other professions I'd had so far, there wasn't a clear path to become a web developer. There were a lot of technologies to chose from, and endless discussions about the best options.
I tried a few tutorials and videos to learn how to program, but the approach wasn't working for me. I realised that I should understand some of the theory and fundamentals, before moving to more practical stuff. I decided to focus on technical books and academic articles related to generic skills, such as HTTP standards, Object Oriented concepts, SQL, HTML and CSS.
The theory helped me a lot to understand some of the magic behind the Rails framework. It also has been helping me to quickly adapt to clients' projects and their chosen technologies. I believe it's much easier to gain and keep a skill when putting it into practice, and therefore I like to prioritise my learning based on client's needs.
Esther Olatunde, Senior Developer
One of the reasons why I love tech is because it's an ever-evolving industry where there's always something new to learn. There's always an old or shiny new concept or knowledgebase to explore. This makes it fun for me but it can also get a bit overwhelming if not managed well.
I like that at Happy Bear we have a culture of asking each other what we want to learn next for self-development. That makes it intentional for me to keep a list of things to learn and helps me weave continuous learning into my routine.
I prioritize my learning based on the client codebase I'm working on at the moment. When I worked on a codebase where VueJS was used, the VueJS doc was my bible for that period. I also learned a lot about automating your development environment on that codebase.
I learn from understanding and fixing weird bugs. When a client recently had a bug on their production environment, I learned a lot about query locks on postgresql databases.
I learn out of pure curiosity. That's how I learned how to build Android and iOS apps. I was curious and I had the time :)
If I'm lucky, the things I'm learning on the job are on my things_to_learn list. At other times, I look through my list and pick what I want to learn about within a period of time. For instance, a few months ago, I decided that I wanted to learn more about ruby internals so I bought and started reading the Ruby Under a Microscope book on a schedule of 10 pages per week (of course, I haven't been as consistent as I'd have loved but I'm still on it). Next on my list is digging into the core of cryptography and machine learning.
Sometimes, if I have a really chill weekend, I can just pick a concept, framework, knowledgebase, tutorial, etc. and dive into it for the weekend. My learning goals are usually geared towards avoiding the noise and digging out the substance as I believe if you understand the core technologies you can pick up any new tool used on the job.
- Najaf Ali