TL;DR;

The top is close or not ...

As a software developer, one of the main challenge I’ve met is to find good resources and feedback to keep my learning curve at a certain level: not steep enough to be frustrating, not low enough to be stalling. There are plenty of ways to do it, especially when it’s the first time you learn a new programming language. After a certain level, it becomes far more complex and slow. I had that frustration and tried to find good solutions. I’ll share that experience.

My journey as a C and C++ developer

At the beginning, I started with C. I learned it before the university mainly by reading tutorials on the web. At the university, I started C++. The courses, the projects and the practical works were good sources of learning. They mainly gave me a list of topics to dig and experiment, and the practical works were the best place to have a quick feedback depending on the teaching assistant.

Old good paper books.

During my engineer studies, I read more rigorous articles on the web and the big classics including C Programming Language by Ritchie and Kernighan or C++ Programming Language by Stroustrup.

After my graduation, I reached a learning plateau. I missed someone with a better knowledge in C++ to give me insight and path of progress. Hopefully, I met him at the beginning of my PhD. He advised me books, content, people to read or listen (e.g. Herb Sutter, Scott Meyers), or tools but moreover I had someone to discuss the challenges and potential solutions. Even today, it’s still someone I come back when I’m struggling with complex problems in C++ or design. During that period I especially learned the benefits of tooling like linter, static analysis, profiler, not only in terms of code quality but also in terms of learning. They underlines problems I wasn’t necessary aware of and give me a point to learn and improve.

The other way I progressed during my PhD was by teaching. When teaching something, you need to clarify and refine your understanding in order to communicate it. Moreover, you need to know the bounds and the exact internal working. It forced me to dig into some topics like the STL.

After my PhD, I worked as a freelancer. In most of my contracts, I was the only developer. Of course, as before, I’ve still read on the web and googled, but when I was facing a big issue for too long, my best solution was to discuss it with one or another friend C++ developers.

As a Ruby developer

I’ve learned and practiced other programming languages such as Java or Python (or BASIC a long long time ago). Roughly one year ago, I’ve started to develop, notably, in Ruby for 8th color. I’ve met another kind of learning challenge.

Shiny!

As a polyglot developer with some substantial experiences and knowledge, I learned the basics quickly. With my level, I’d expected to learn enough knowledge to write not so crappy code. But even if there is a common pattern between programming languages and the algorithmics fundamentals are still the same, the idioms are different, the ecosystem is different, the tools are different, the learning sources are different. I still have a lot to learn and experiment to reach a satisfying level in Ruby.

Even if it exists great active learning resources such as code school or codecademy, once I’ve finished them, I was far from what I’d expect as minimum level. It took me time to find the good blogs and the good tools. It was interesting but not essential for my progression, I’d have prefered to spend that time to learn about Ruby itself. Hopefully, Martin learned Ruby in a same time and I had someone to discuss and share with.

The way to learn

From my experiences, I’d summarize the different ways to learn as following:

• books, blog posts, tutorials, podcasts, conference talks
• forum, stack overflow questions, mailing lists
• interactive applications (code school, codecademy, robot war)
• tools (linter, checker, static analysis, profiler)
• close developers (colleagues, friends, coach)
• developers (forum, stack overflow, mailing lists)

a model of learning slope (Photo credit: Wikipedia)

All of these participate differently to your learning. If well chosen and used, they have all their utility for any expertise level. For instance, tools and close developers are very good to support active learning, i.e. learning by doing. Interactive applications are certainly the best for a beginner. Books can present very introductory materials as the more advanced, but they’re only passive knowledge.

I can probably spend another blog post to describe their benefits and drawbacks, and categorize them according your level. But I’d prefer to underline something else first: having the right feedback at the right moment.

The learning challenge for a developer

I used to be the typical profile of lone developer: no pair programming, no team, no senior developer. I need to rely on myself and on some close and trustable peers. In learning, it’s not an uncommon situation. You cannot rely on someone else to support you and give you good feedback to frame your learning. Sooner or later, you’ll inevitably wander in the dark. It could be because the content you’ve found it’s not good enough, or simply because you don’t know where to go first. I’ve experienced it as an experienced C++ developer and as a beginner Ruby developer. It’s a big frustration.

It’s a kind of situation you can also meet even when you’re working in a team, especially during stressful phase with close deadlines. You don’t have always someone available to answer you when the question pops out. If it’s a stupid one, you probably don’t want to interrupt them as the flow is important.

I’ve discussed that learning challenge with several developers. It’s usually accepted that it takes time and having someone helping you is a must. For me, the time is certainly a pain, but my biggest frustration is the loose and inadequate feedback for my level. My best learning experiences are when I’m facing a certain problem, I find the good blog post discussing the problem, and I can finally try it and implement a solution.

What are your experiences? Your biggest pain? What are your best learning mean? How do you keep improving year after year ?

Introduction

I used to be a team leader, before starting 8th color. Now we are a small development team here (the three of us) at 8th color, and I’m still advising some other teams about their methodologies.

This made me think again about what it means for me to be a team leader, and some experiences that could hopefully help some developers aiming for the function.

What is this about?

In my experience and vision, being a technical team leader is first and foremost being a team leader. The technical part is there, of course, but people are what matters, and what you should concentrate on. No amount of technical prowess will save a project if the team is not working. I found three analogies that worked for me.

Nooooooooooooo ! (Photo credit: Wikipedia)

Being the foreman

What made the difference between a project manager and a team leader is that I always saw my position as the one of a foreman. When people ask me “they are working for you?”, I tend to answer “they are working with me”. It’s a slight difference, but a potent one.

Being a foreman means that you are directing the crew, but from the middle of them, not from the outside. My father used to direct a garage crew. As a foreman, he was not putting the tires himself, but he could still go in the hole under the truck to look at the job or give advice. I’m always in the hole. I call the shots, but can get my hands in also. That is important for me, to keep up with the reality of the work, and for the other developers also, as they know they can count on me to help, not just manage.

Gatekeeping

My definition of my job is always to be the gatekeeper: I am there to be interrupted, so that my team will not be. I did impose a rule at some point, not on the team, but on the external world: all interruptions or signals (mails, people, phone calls) were to be directed to me. Should it requires to interrupt a team member, that decision would be mine. The positive impact is to allow the team to be focused and productive. The bad one is that it meant to split my time in 15 minutes chunks. Better one person than five, anyway.

Moving furnitures

Your team cannot code in the middle of this. (Photo credit: Arthur Chapman)

A colleague of mine once expressed his job of team leader as “moving furnitures, to be sure that developers had enough space in the room to work”. In other words: removing impediments. Achieving the business goals is your team work. Yours is to remove any obstacle for them to achieve it.

Trust people to get the job done

This is a very pernicious problem : being a technical team leader means that you are in charge of people and able to do their job. The key is it is not because you are able to develop a feature that you should do it. Not even if you are the most capable person: you did decide to take a job with different responsibility, you should work on those first. Someone else can manage the feature, but no one else will run the team if you are busy digging into code with your headphones on.

I tak with a lot of non technical people managing developers, telling me how difficult it is, because they do not understand the job. Becoming team leader when you were a developer looks easier to them. It is not. There is nothing more difficult than to let people work on something, when you know their job and think that you could do better. After all (and it is one of the flaw of the system), most often, good developers get promoted to team leaders.

Being a team leader is all about supporting your team,, helping them, but moreover trusting them to get the job done by not doing it for them.

Take the shots, call the shots

This is something I strongly believe about every management function. When I am in charge, it means than any defect in my team is my responsibility. The basic consequence is simple : if someone have to complain, it

Be prepared to take some shots for the team. (Photo credit: Wikipedia)

complains to me. If the team made an error, it is my task to apologize and/or assume the consequence. Whoever caused the initial problem, it is my job to ensure it does not happen. The other side of the coin is that of course, if someone in the team did fail, I’ll have a discussion with him/her, and see that it does not happen again. But I’ll have this discussion personally (not my manager, not the customer that did support the consequence of the error) and privately. You have the “right” to call the shots in the team because you take the shots for the team.

Warning to those tempted

If you are a developer reading this, and tempted by making the shift to being a team lead, I’ll offer two nuggets of “experience” (wisdom is only given by old people with long, white beards) that may help you decide whether it is a good idea.

Following people is a full time job

Should you start doing some “coordination” for a small team, let say 5 persons, this will probably eat all your time, at least if you want to do it “properly”. That means that you’ll have very little time to code, however able you can be. I still open my IDE everyday, but most often than not, it is to review something, not to build it. If you like to build software, be aware of this. You may be building your last.

My previous boss advice

But I -want- a Pony ! (Photo credit: Wikipedia)

Some years ago, I was a reasonably happy developer working at a large company. I enjoyed some kind of “lead developer” status in my team (even if my official title at the company was “developer”). At some point, I thought that I “deserved” some recognition in this (my team did not have a Team Leader at the time,  and I was doing the job).

So, I went to my manager to ask (sort of demand) the position. She looked at me and said “If you want it, I’ll support you on this to the top management (who needed to approve those kind of promotions). But think about it carefully. Be sure that this is what you want”.

At that time, I did not really though over it twice – I was pretty sure I had the required skills and that I basically did most of the job already. Of course I wanted it! No one did contest that, and I got the position soon after (with some monetary benefits). End of the story, except for one thing. The good question would have been: would I be happier in this position? Fact is, since then, I did far less coding, as other tasks began replacing the coding ones – like coordination and, even worse, meetings.

A couple years after, I considered moving up the ladder again. I thought about it carefully that time, and decided not to: team leader was the last position where I could expect still doing some practical stuff. I was coding few features, but was still opening my IDE every day. The next step would have been exchanging my IDE for an MS Project.

In her words: “Be sure that you really want it”. Or, as the popular quote goes

“Be Careful What You Wish for ’cause It Might Come True”.

Conclusion

I took and still take a lot of pleasure working as a team leader. I find the function immensely rewarding. But it is a totally different job than being a developer. Both are interesting in their own way. It is not because one may be better paid or of higher status that you’ll be happier in, and that is what should matter. Good developers frequently make bad team leaders or worse : unhappy team leaders. Be careful.