50 People’s Opinions About How To Get Better As A Software Developer

Last week I attended the Software Craftmanship Meetup in Paris and, like every time, everyone went away inspired by the ideas that were shared during the evening.

This time the debate was about the methods to get better as a software developer. And since the 50 of us vehemently expressed their satisfaction about the enriching evening, I thought you may well be interested in what came out of that evening too. So let me share it with you.

Contrary to the previous meetup I summarized, this one is not about expressive code per se, but I’m assuming that if you read blogs then you probably are interested in becoming better as a software developer.

The process we chose for the debate was that every person would start by stating what the most important thing to do to improve as a software developer was, in his or her opinion. This made a vast list of topics to explore. Then we would have five minute debates on several of these topics, where people could ask questions and share their experience. Here is what I retain from it.

Keeping up with technology

How to keep up with the constantly evolving technology? And even before this, how to acquire the numerous best practices that are already out there?

One way to do this is to read books. But one question comes with it: where do you find the time to read them? This is a problem for so many of us. There are so many books I wish I could read, but I just don’t find the time for it. Don’t you have the same problem?

One person shared a simple technique: read 20 minutes every night. According to his experience, finding 20 minutes every night is doable, and with time you can read a fairly large amount of books and keep on the top of your technology.

Another technique is to read with other people. This is not about actually reading side by side, but rather setting a common goal of reading a book with other people. There are various ways to organize this.

In my company for example, I have put reading groups in place. We are 5 to 10 people in a group, in which we agree on a book we all want to read. We meet twice a week, 30 minutes each time. A few days before the first meeting, we agree on which chapters we will have read by the meeting. Then when we meet, someone starts by quickly summing up the contents we all read, then people can ask questions, share their experience, and as a group we debate how this can be useful for our daily work. Often this sort of debate bring up things that go way beyond the book itself. Then we agree on which chapters to read for next time. And so on.

The advantages of this technique are:

• we end up having read the book: there is a manageable amount to read every couple of days, and the fixed moments to meet with the group motivates us to actually do it.

• as a group we learn much more than if we had read it individually.

One thing we didn’t cover during the meetup though is: how do you find the right books? If you have insights about this, you’re more than welcome to share.

One book that is unanimously recommended though is Code Complete by Steve McConnell.

Going past the fear of failure

Sometimes learning takes the form of making an experiment. And one particular experiment can succeed, or it can fail. This perspective is enough to deter some of us from trying it, forgoing the learning benefits that were to come with it. And sometimes such an experiment is visible to other people, which make it even scarier.

How to go past this wall of fear, and actually try things out and move forward?

One way is to set a limit to the resources that are at risk in the experiment. A consultant explained how he encouraged some of his clients to try out new things by setting a time limit. For example doing your best on a new thing for an hour, or two hours, of half a day. If it fails then you would have lost this amount of time only. And if it succeed, you would reap all the benefits from it.

This aspect of a time limit was also brought up during the debate of “learning by doing pair-programming”. Some developers had a hard time convincing their colleagues that pair programming could be beneficial. One solution shared by somebody was to sell it as an experiment: let’s try pair programming for two sprints, and decide if we should stop it only at the end of this period.

Another way to do this is to embrace failure. Seek it and welcome it with open arms. This is such a surprising thing to say, isn’t it? This is one of the (so many) things I have learnt from John Sonmez, in particular by reading his incredible book, Soft Skills.

This doesn’t mean you should try to suck, of course. Nor putting off work by thinking that it is OK to fail.

What it means is that you should try to put yourself in new situations, that you’re not necessarily comfortable with at first. If you don’t have much experience in speaking in front of people for example, then you can just try and start doing it. Or if you’re not familiar with a new technology, why not try to make a small project by using it? Doing things that have a risk of you not doing great the first time is where you actually learn, whatever the outcome. And in many situations, failure is not such a big deal anyway, like in the above two situations.

If you are from the more experienced people then you can try to make it as easy as possible for the younger members of your team to propose new things. Like not being too harsh while reviewing their code for example. One technique that a participant shared is to always start a code review by saying something sincerely positive. Another attitude that was proposed was to be “hard on the code, and soft on the people”.

Attending conferences

There was a clear consensus that attending conferences was a good thing to progress as a software developer. But we were at a meetup so maybe this one is just a tad biased 🙂

Anyway, there is a barrier to entry to conferences: their price. Some conferences charge several hundreds of dollars for the entrance fee, and if they are abroad you need to add up plane tickets and hotels rooms to the bill. That can be a pretty large amount of money, enough to deter many to attend. What to do then?

One way is to have your company pay for it. There are several arguments that would encourage a company to send their employees to conferences:

• seeing it as a training: the few people that go can in return share what they learnt there with the rest of the employees when they come back. This way, the cost of sending you to the conference is split over many other people too. But careful, it takes some work to synthesize the things that you’ve seen into presentations.

• using it to improve the company’s image: if you post picture of the team off to the conference premises on social media, like on the Twitter account of your company, this can make the company more attractive to potential applicants.

But some events are completely free to attend, such as meetups. You are even offered diner in general when you go there.

Another route to conferences is by applying to talk there. Speakers generally get in for free, and some conferences even pay their speakers for their intervention. But being accepted as a speaker is not often an easy thing. Some conferences prefer if you provide a link of you speaking somewhere else, making this a circular dependency.

One way to break the dependency is to start by proposing to speak at meetups and user groups, which are much more open to new people.

Getting yourself a new work environment

Changing of work environment throws you in a new situation where you suddenly have many exciting things to learn.

But a new work environment does not necessarily mean getting a new job in a new company, nor even getting a new position in your current company. Of course in some situations this is the right thing to do. But one of debates we had showed that there are many other ways to change your work environment, not as drastic and much easier to put in place.

One is simply to move to a new project, and thus work with new people. We learn so much from our co-workers. The younger ones have great questions, and the more experienced have great answers. So working with new people can offer you new perspectives on software development.

Another one is to try a new technology. The idea here is to try something really different from the technology you’re working on. Not just a new language, but go for a new programming paradigm. If you’ re an OO developer, why not give a try to functional programming? There are so many resources online to learn Haskell, Scala or F# for example. Even if it is just for a side project, this new point of view can cast a brilliant light onto your main programming language.

I will leave the last word on this subject to Damien Beaufils: change seats! We naturally tend to ask help and chat with our immediate neighbours. And as was mentionned earlier, we learn a lot with people. So let’s meet more of them by moving around in the office space, which is generally a very easy thing to do.

I hope you found these ideas useful. Oh and, if you’re around Paris, why not pop by the next event?

Don't want to miss out ? Follow:   
Share this post!