Patterns of a Cool Programmer

It all started when I began reading programming books from different authors – books such as ‘C# for Dummies’, ‘What is HTML’, ‘ActionScript for Dummies’, ‘Clean Code’, ‘Refactoring’ and others. Aside from the technical mind-twisters these guys we’re throwing at me without mercy, I realised that they were only sharing their experiences and showing me how, when they found themselves in a difficult situation they fought and came up with solutions.

Also, watching presentations and keynotes from great devs such as Dennis M. Ritchie, Linus Torvalds, Steve McConnell, Kent Beck, Martin Fowler, Uncle Bob, John Carmack, Scott Hanselman, David Heinemeier always gave me that reassuring feeling of listening to a cool guy sharing some cool knowledge.

Cool Programmers

The stories these guys were telling and the way in which they approached things started to haunt me. In the end I said to myself ‘I want to become a programmer! I want to be as cool as them and do amazing stuff.’ And so I became one.

My first encounter with the tech world was not as cool as I expected. I found myself working with many people, all of which lived with the premise that code is perfect as it is and that it does not need any testing – testing is for weak programmers. What’s worse is that I also inherited this way of thinking.

I realised that in less than 3 months I became a phony dev – a totally different person from all those cool guys I was telling you about before. A person who did not accept the fact that code had issues too and that these issues have to be shared and dealt with.

I took a step back, analysed everything and thought about what a cool dev would do in situations like these. Well, he would CODE & COMMUNICATE, get rid of all vulnerable feelings and go back to the drawing board! I understood right then and there that it all starts with our limits.

Limits

First you need to acknowledge your limits and then enlighten yourself. Accept the fact that you have limits, that you don’t own every topic, and then exceed these limits.

This is not a one-time deal – it’s repeatable and it should be done as often as possible. All cool programmers I’ve listed at the beginning of this article admit they do it all the time.

Also, being open to learning new things implies being open to feedback. Yes, FEEDBACK! If you’re not open to feedback you’ll start suffering from something called ‘The Imposture Syndrome’. I read a blog post about this once. The main point is that if you do not accept feedback, you might end up in two traps: the one in which you become the best programmer Mother Earth has ever created (please sense the sarcasm here) or the one in which you become the worst programmer ever and you need to change careers. Feedback lets you always know what your real value is and helps you evolve.

So, yes! One of the patterns of a cool programmer is that he admits his limits and continuously strives to overcome them.

Hungry

You remember Steve Jobs’ speech at Stanford University, don’t you? ‘Stay hungry. Stay foolish.’ I think this was the smartest thing he ever said. 🙂

After my first encounters with the programming landscape, I realised I needed something to keep me at ease. I started to be hungry as Steve suggested. I was hungry for technology, eager to try out anything new and unknown. I would jump, dive without a parachute into anything (I am going to subtly insert Tomcat’s error here: P “2015 6:18:25 AM org.apache.tomcat.util.net.NioEndpoint checkParachute SEVERE: SEVERE:Memory usage is low, parachute is non existent, your system may start failing.”)

Every cool programmer I’ve read about tried a lot of things. It keeps you on track, it keeps the flame burning and makes it possible to find good solutions. Because good solutions can come from past experiences and knowledge that might not seem related at first.

Humble

When you’re hungry and you start discovering a lot of stuff, you risk turning to the dark side and becoming vain. Cool programmers are not vain. Cool programmers are humble.

snob

Being humble is about having the right attitude and not rubbing your personal success in everyone’s face. It also means that when you see a team struggling, you don’t go over and start pointing fingers like Captain America. If you’re a cool programmer and you know how stuff can be done better, you go there and help everyone do it better. Someone’s problem is everyone’s problem.

Humbleness has other aspects to it as well – aspects regarding failure. Being humble means you have the power to admit that you’ve done something wrong and take action to correct it.

Kent Beck once pointed out that girls cannot code. He actually said that in a post of his. After his daughter became a programmer (and she was rocking it too) he saw that he made a wrong move. He published a post on Facebook open to everyone in which he apologized for his statement. He wasn’t afraid of the 2 million developers seeing his post.

See? Now that’s HUMBLE.

Insane

We’ll talk about insanity, but first let me make myself clear here – I’m not talking about the bad kind of insanity, but about the good one, the one that makes you stand out of the crowd.

We usually laugh at devs with weird ideas and make fun of the way they keep sticking to their guns. But you never know when their crazy ideas will actually become reality. Take Git for instance.

Craziness is not a pattern found in all programmers, but sometimes is can definitely help.

Full Stack

Let’s get into some technical philosophies. Is it a good thing to be a full stack dev or not?

There are many discussions on this topic. In my opinion, the word itself is clearly misunderstood. It comes on too strong, while it is common sense that no one can know everything there is to know about everything. But that doesn’t mean that you cannot have a larger stack of technologies in which you can have certain levels of expertise.

Let’s say you are a great SQL developer, a real tech savvy in the domain. It definitely doesn’t hurt your team if during a project you also help out with a little bit of coding in the backend, solve some small issues on the frontend, maybe fix some bugs or help with the CI setup or the deployment activities, right? You don’t need to be an expert in all of these, just have some extra knowledge besides SQL.

In my spare time, I’m a Dota player myself. I don’t know if you’re familiar with the game: you play it in teams (5 guys versus 5 guys) and you get to have a hero identity and different abilities. You can choose to be part of one of the following categories: Carry (main damage dealer), Initiator (initiates attacks), Support (heals, offers map vision, helps at ganging on lanes), Tanks (heroes that can take on a lot of damage). Now, the dynamics of the game makes it really difficult to stay in just one role throughout the whole thing. You need to adjust your role according to the team’s needs. There are moments when a Carry becomes a Supporter, then goes back to damage dealing, when a Supporter becomes Initiator and the Initiator becomes a Carry.

The same applies in a team of programmers. Nowadays, people adopt the agile methodology – you dive into 2 week sprints and deliver some software. Can you stay in that sprint just as a Carry (SQL dev)? Or do you find yourself in the position that you need to do some frontend too (Initiator)? What about writing acceptance tests (Supporter)? What about backend (Tanks)?

Let’s visualize everything. This is impossible:

FullStack Programmer - impossible

This on the other hand is possible:

FullStack Programmer - Possible

To sum it all up, a cool programmer should know other things besides his main technology of expertise.

Team Player

I talked a little bit about teamwork in the sections above. Let me just share some last thoughts on the topic.

How would you like your team to be like? The best developers the earth has ever seen with low team play? Or a team of medium to low programmers but with extraordinary team spirit?

I personally will always go for the second choice, the ones who know what teamwork is all about. With them you can always be sure that the project won’t fail. Even if you mess something up, the team is there to help you through the tough times and fight for success.

Team players are cool, no doubt about it. 🙂

 

So these I think are the patterns of a cool programmer: striving to exceed one’s own limits, being hungry for knowledge (knowing more than one technology) whilst at the same time being humble, a great team player, and if a little bit of craziness is thrown in there as well, the better.

What do you think makes a programmer cool? Share your thoughts in the comments section below.

Tags:

You can be the first one to comment on this story.

Leave a Reply

Your email address will not be published. Required fields are marked *