It all started when I began reading programming books by different authors – books such as ‘C# for Dummies’, ‘What is HTML’, ‘ActionScript for Dummies’, ‘Clean Code’, ‘Refactoring’… Aside from the technical conundrums these guys were throwing at me without mercy, I realised that they were only sharing their experiences and showing me how they fought and came up with solutions when they found themselves in a difficult situation.
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 enlightening knowledge.
The stories these guys were telling and the way they were approaching 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 had expected, though. I found myself working with many people, all of which lived by the premise that code is perfect as it is and 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 had become 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, then dealt with.
I took a step back, analysed everything and thought about what a cool dev would do in situations like these. Well, they would CODE & COMMUNICATE, get rid of all those feelings of vulnerability and go back to the drawing board! I understood right then and there that it all starts with our limits.
First you need to acknowledge your limits and then enlighten yourself. Accept the fact that you have them, and 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 the cool programmers I 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 ‘Imposter Syndrome’. I read a blog post about this once. The main point is that if you do not accept feedback, you might end up caught in two traps: the one in which you become the best programmer Mother Earth has ever created (please note 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 they admit their limitations and continuously strive to overcome them.
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. :slightly_smiling_face:
After my first encounters with the programming world, I realised I needed something to keep me at ease. I started to get hungry as Jobs had 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. This 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.
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.
Being humble is about having the right attitude and not rubbing your personal success in everyone else’s faces. 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 else’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 revised his attitude and admitted that he had been wrong. He published an open post on Facebook in which he apologised for his statement. He wasn’t afraid of the 2 million developers out there seeing this post.
See? Now that’s HUMBLE.
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 found in all programmers, but sometimes it can definitely help.
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, that doesn’t necessarily mean that you can’t have a larger stack of technologies in which you can have certain levels of expertise.
Let’s say you are a great SQL developer, and real tech savvy in the domain. It definitely doesn’t hurt your team if you also help out with a little bit of coding in the backend during a project, 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; you just need some extra knowledge besides SQL.
In my spare time, I used to be a Dota player myself. I don’t know if you’re familiar with the game: you play it in teams (5 versus 5) and you get to have a hero 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 make 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, or 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 visualise everything. This is impossible:
This, on the other hand, is possible:
To sum it all up, a cool programmer should know other things besides his or her main technology of expertise.
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 no team players? Or a team of medium to low programmers, but with an extraordinary team spirit?
I would personally 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. :slightly_smiling_face:
So, I think these 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 and a great team player. Oh, and if a little bit of craziness is thrown in there as well, all the better.