Education. In a fast-changing environment such as the web industry, education is the single most important thing to survive. The things I learned about PHP when I started doing PHP 17 years ago would not even get me a job anymore today. Where traditional jobs mostly require just the standard education with a short course every once in a while, the web industry is vastly different. New technologies still arise every day, new insights on how to organize your project or manage a team are published on a regular basis. We need to stay up-to-date on those subjects to ensure we keep doing the right things in the right ways. It is impossible to keep your knowledge on everything up-to-date and still have enough time to work, so we need to make choices on which topics to focus on and how to learn. In this article I’ll go into some strategies and some ways to keep the knowledge of you and your team current.
Generalist or Specialist?
There’s always been an ongoing discussion on whether you should be a generalist or a specialist. Both are highly desirable (a backend developer with good frontend skills is rare, so being one will make you really interesting for companies, but someone who has specialized in a specific technology knows more than anyone else about that), but you can’t do both. You can’t specialize and be a generalist. So first, decide on which one you want to be. Then make a choice on which topics you’ll want to learn more about.
Ways of getting more knowledge
So let’s have a look at things that you can do to improve your knowledge and the knowledge of your team. Some are easy, some are a bit harder, but all of them can be used to improve the knowledge of you and your team.
Never underestimate the amount of knowledge within your own team. Every single person in your team adds knowledge to your team (otherwise, why would you have added them to your team in the first place?). So use that knowledge! Organize a knowledge session in which one of your team members will present some of their knowledge to the rest of the team. It does not even have to be seniors and team leads presenting to juniors or mediors, anyone can present on a topic they want to present on. This can be anything, from something they learned while they were building their own personal website to something they worked on in one of the recent projects.
Some companies do this during worktime (Friday is a perfect day for this, it is usually the least productive day of the week), some companies do these during the evening (a so-called pizza session, where pizza is ordered and knowledge is exchanged). Both have their advantages and disadvantages, so it’s best to simply look at your team and the people in it and decide based on the preferences of the team.
Attending usergroups is very similar to the knowledge sessions, with the difference that you’re not organizing it yourself but you’re joining a group of peers to listen to their stories. The easiest way to find a local usergroup is to check Meetup. Attending usergroups is usually free, it just takes some of your free time. The additional advantage of attending a usergroup is that you meet people. These contacts can be useful when you’re recruiting, or simply when you’re solving a problem those contacts have solved before. So aside from the knowledge you learn yourself, you also extend your knowledge network.
A funny thing about conferences is that you usually don’t get a lot of knowledge from being there. This, however, does not mean they’re useless. On the contrary, conferences are very useful, because you get exposed to new things everywhere you go. There’s only so much one can share on a stage in 45-60 minutes, but it’ll inspire you to dig further when you get back home or back to work. It’ll plant a seed in your brain that you may not immediately need, but once you encounter a problem at some later point you’ll think of and it will help you solve your problem. And, just like usergroups, you meet people. You expand your knowledge network with more people that, one day, will help you solve a problem. Sometimes just by listening, sometimes by actually helping you out.
This is the most traditional way of education, but it should certainly not be discarded. Training sessions are usually a great way of getting some new knowledge on a subject. Look beyond the major educational organizations towards the smaller initiatives. The feedback I’ve been getting for WeCamp for instance has been really good. Recently, DWA member Joshua organized an amazing masterclass. It’s usually the relatively small initiatives that are really useful, so look beyond the big organizations for the specific knowledge or experience you need and don’t be afraid. Just do it.
Small Controlled Experiments
There’s learning you can incorporate into your day-to-day work as well. Next time you’re not sure if something works, consider small controlled experiments. It is a great way of learning whether a certain approach may work. The idea is that you won’t know whether something works until you try. You could spend hours on a discussion on the merits and downsides of an idea, but you could spend the same amount (or a little more) on actually trying whether it works. If at the end of the experiment you have to conclude it doesn’t work, the time is certainly not wasted: You’ve learned a thing or two about the chosen approach. And remember, failure is essential to learning. If it does work, then you’ve learned by doing and you’ve got something to show for it.
Similar to the small controlled experiments, though with a slightly different background and purpose, is the code kata. The idea behind a kata is that the only way of really learning is through experience, so that’s similar to the small controlled experiments. Where it differs though is that with the small controlled experiments you usually experiment with something you actually get from work, and with the code kata you instead take a topic you’re simply interested in, or you can even take a random topic (there’s a long list of examples on the code kata website). Learn by doing, by failing and eventually succeeding.
Pair programming has long been a proven method for both code quality and productivity, but you should also consider the educative value of pair programming. Instead of just one way of thinking about a certain problem, all of a sudden there are two. Every developer looks at a certain problem in a slightly different way, from a different background, with a different solution in mind. The result of sitting down together to work on the same problem means you’re learning from eachothers experiences and backgrounds. Next time you work on a similar problem you will now have the experience of two people in your head instead of one.
A similar thing as with pair programming happens with code reviews. An extra set of eyes looks at the code and the chosen solution, and any feedback given will teach the author of the code something. As I’ve written in Wisdom of the elePHPant, code review feedback should not be taken as criticism on you as a person or your skills as a developer, but as input for further learning, as lessons for the future.
Additionally, the reviewer also learns. They learn from reading someone elses code, from having to try and understand the choices the other developer made, the considerations they put into the code they’ve written. So code reviews are beneficial not just for code quality, but also for both the reviewer and the reviewee.
There’s two educational sides to documentation that are important: Reading and writing.
First of all, the most obvious is: RTFM. There, I said it. Reading documentation may seem boring because, well, it’s reading, not coding, but actually taking the time to read documentation can teach you a thing or two about the software or library you’re using. It may also save you time in the future because you already know about how things work before you actually get started with it.
Then there’s writing documentation. When you’ve written a piece of software or a library, and you’ve been knee deep in the code, having to write documentation for that software will make you step back from it and look at it from a different point of view. This will teach you a lot about your code and your software. All of a sudden you’re looking at it from the users point of view, and that may actually make you reconsider some of the choices you’ve made while coding. As such, writing documentation should not all happen after coding, you should regularly write pieces of the documentation. It will help you write your software as well as teach you a thing or two about your code.
And documentation goes beyond the standard manuals and API documentation. Consider a blog or a magazine. Writing blogposts and articles will teach you about writing, about explaining and about that coding problem or library you’re writing about. Writing this article has taught me more about the concept of a code kata and even about event storming, a subject I decided to leave out of the article. But I still learned.
A mentoring system, whether you do it within your own organization or outside of it, will help you. Being a mentee will teach you a lot, because of the knowledge you get from your mentor. And being a mentor will teach you a lot about knowledge transfer, about helping others and about how other people think and do. Just like with documentation, both sides of the spectrum will teach you something.
There’s so much more…
You learn something every day. With everything you do, you learn. A lot of times you won’t realize you learned something and you will simply apply your experience to a situation in the future. Sometimes you do realize you’ve learned and you can share the lesson. Most importantly though, you keep learning. In software development, no two challenges are the same, and technology moves forward with such a high pace that we can not escape learning. As long as you have a healthy appetite for learning, you’ll be fine. And with the above list, you now have some more ways of learning. Feel free to share your lessons, so more people learn.