Attitude Counts
By Gavin Davies
What Do I Wish I’d Known?
I got started early - I wrote my first code around age 4. I left Aberystwyth University in 2001 with a first class honours in Computer Science and Geography. At this point, I felt fairly confident that I knew a lot about software and I took my first job at a small web company. For a large amount of my time there, I was the only full-time dev in the company. Over the next few months, I learned the skills I would need (basic PhotoShop, ASP classic, HTML and a little CSS) and off I went, building web applications. My work perhaps wasn’t my particularly high on my list of priorities*; I was in a rock and roll band, and we had moved to Cardiff as a unit, but work paid the bills and life was fun.
(* work still isn’t the be-all and end-all, I just think I’m more diligent about it now!)
I was pretty bright back then, and I could pick things up quite quickly. I started to think I knew it all, and anything I wasn’t comfortable with, I kind of glossed over. I had ability and youth, but I did not have a particularly good attitude. I was quite arrogant, despite the fact that, in all honesty, my code quality was actually pretty shocking!
Perhaps even worse, in my early career, I could be pretty condescending to clients. I remember once a client asked me for a change that I felt violated best practice and I wrote down in my notes, speaking it aloud, “break the user interface”. Pretty appalling customer service!
I look back on those early years and I cringe. I had a terrible attitude. I could have made far more progress, professionally and personally, had I had my attitude right.
Here’s my wishlist:
- I wish I’d had a sense of how much I didn’t know.
- I wish I hadn’t thought I was so “complete” as a software developer.
- I wish I had been more humble.
- I wish I had worked harder to find the wider technical community.
- I wish I had treated clients with more respect.
See, nothing on this wishlist is particularly technical, it’s all about my attitude. I believe that the way we approach what we do is fundamental, analogous to the foundations of a building. All the technical skills in the world won’t make people want to work with you if you’re unbearable!
In addition to looking back on my own behaviour, I’ve worked with coders with poor attitudes, which can really have a “bad apple” effect. It only takes one person to ruin a team - don’t be that person! In particular, I’ve worked with lots of young guys fresh out of Uni or with some freelance experience who have thought they knew it all, so I’ve seen how bad that is - it’s next to impossible to work with someone who simply won’t be told anything!
Let’s have a look at the finer points of attitude and see how we can think about what we do.
What Does A Good Attitude Look Like?
There are some things that the greatest people I’ve worked with had in common. I’ll take a look at some of them.
The Best Coders Are Willing To Share Knowledge
A good coder is willing to share knowledge, not jealously hoard it like some “knowledge egg” that inevitably begins to rot and stink over time as it is surpassed. We should not feel that we are in competition with one another - in my experience, the more we share, the more we fill in the cracks in our own knowledge. Teaching is one of the most powerful learning experiences of all.
The Best Coders Are Brave Enough To Show Ignorance
The counterpart of being willing to teach is being willing to learn. None of us know it all, that’s impossible - our field explodes with new libraries and approaches every day!
You will be ignorant at some points in your career. That’s OK. I’ve stopped trying to hide my ignorance. I will ask questions. It just takes a little courage.
If you find yourself sitting there at work, not knowing what to do, my advice is to ask questions until you do. You could request to shadow a more experienced colleague, ask if there is any documentation, chat on your company’s IRC or mailing list, or raise issues in a daily meeting. There is very little that is more stifling than to sit in painful ignorance, too afraid to ask questions.
The Best Coders Remain Humble
It is really tedious to work with someone who is always showing how clever they are - I suppose it’s often rooted in insecurity. Some coders act like they know all they will ever need to know - not so! This is never the case, and it can really discourage those around.
A humble attitude can encourage others. Humility isn’t about sitting there wailing “oh, I’m rubbish, woe is me” - rather, being humble is about recognising that we don’t know it all, that we have much to learn, and that those around us have good ideas too!
The Best Coders Are In The Community
The image of the lone, gruff, uncommunicative coder is not an archetype that young software developers should aspire to. It’s not like that these days, or at least it shouldn’t be.
I am fortunate enough to work with dozens of software developers where we have tech talks, an IRC channel, we send links around, talk code and so forth. If you don’t have that community in your workplace, perhaps you can start it. If you’re at a smallish shop, or are a lone dev, there are tech meetups, conferences and unconferences (whatever they are!), user groups, coding dojos, IRC channels, and the bustling open source town square that is Github. Being in the community expands our thinking, introduces us to new concepts and tools, and constantly challenges us.
The Best Coders Aren’t Precious
Always try to get more experienced coders to look over your work. It’s hard not to think of your work as “part of you” - criticism can sting - but lay that aside as best you can. A code review is perhaps the quickest way to get good feedback and improve your work.
A bad coder will be protective over his or her source code, because he or she knows deep down that it’s not perfect. A good coder will seek out advice.
The Best Coders Pressure Test
The software industry is high-pressure. I really hope nobody has pretended to you that it isn’t! Therefore, you must pressure test your software. Unit tests should be part of a project from day one. Measure, don’t guess. Run automated vulnerability scanners. Use coding standards checkers and mess detectors. YOU want to be the one to know the weaknesses of your “style”, not some script kiddie. Make it part of your build loop if you can.
The Best Coders Learn Transferable Conceptual Skills
Hopefully, university will have given you a decent knowledge of how a computer works. You’d be surprised how often a modest understanding of binary arithmetic has helped me to understand a problem! There’s so much to learn that picking up the concepts behind things, rather than the latest technology, is really important.
For example, if you’re using a library that has a fluent interface, you could look it up - what is a fluent interface? How do you write one? What are the pros and cons?
Or, if you use a bit of Clojure in a project, you could look up what paradigm the language uses, and do a bit of reading around why it is the way it is, where it came from and so forth.
Similarly, if you’re used to MongoDB and then you have a go at PostgreSQL, you might ask “what kind of database is this?” and look at some of the concepts behind relational databases.
Implementations vary, but concepts carry. Keep reading books and articles!
The Best Coders Take Care Of Themselves
I’m at my most productive when I’m eating a decent diet, getting a bit of exercise and sleeping well. It’s very rare that anyone can code for days straight like you hear about coders doing - most of that is just bravado. For me, there ARE times when I get “into the zone” and hours vanish like seconds, but that’s not every day by any means. Furthermore, Bob Martin (who is a guy you should read) argues that “the zone” can be harmful because it tends to focus on our joy in coding rather than delivering what the customer needs … I’m not sure that’s always the case but it pays to consider whether you’re working efficiently or you just feel like you are!
Resist pressure to do excessive overtime - you’ll burn out, and burnout is absolutely NO FUN at all. Instead, put in a good 8 hours at work - not messing about, getting down to some graft - and do the fun stuff outside work. In your spare time outside work, I’d advise you to tinker around with new technologies, try things out, work on your typing, learn some new shortcuts, read some books and go to tech meetups or conferences - all these things stretch us as coders.
The Very Best Coders Manage Expectations
Some of this section is inspired by on Bob Martin’s “The Clean Coder”, which is definitely worth a read in my opinion.
You will be expected to deliver a lot. This pressure can be good because it stretches us, but be careful - it can break even the strongest of us if we are spread too thinly (e.g. too many projects at once, or an unrealistic deadline). That’s why we have to manage expectations of what we can do.
You will have to say “no, I can’t do that” sometimes. That’s not being negative, that’s in the interests of the company - if the company, based on your estimates, commits to something and doesn’t deliver, that can be a huge problem. With that in mind, however, you must be RELENTLESSLY POSITIVE in your outlook.
Here’s what I mean, demonstrated by a contrived scenario!
A project manager says to you “can you deliver features A, B and C by Monday”. You don’t think that’s realistic. Which is the right answer?
- a. “You’ve got to be kidding!”
- b. ”I’ll do my best” and work all weekends
- c. “I will deliver A and B by Monday, can the client wait for C?”
If you answered (a), then sorry but that’s going to put your PM into defensive mode. Remember, he or she is under pressure too, often more than you are. Always be polite and positive in your language and treat people as you would wish to be treated.
If you answered (b), well that’s not healthy. Every so often overtime can be productive, but maybe you won’t deliver anyway. It’s certainly likely that you’ll cut corners and deliver a bad product. Tired code is sloppy code. Any code I’ve written where I haven’t written unit tests and used a coding standard and mess detector is significantly worse than code I’ve done “properly” - AND it ends up taking longer! I’m not kidding!
If you answered (c), well done! You’ve committed to something you think you can realistically do, and you’ve opened a dialogue to discuss scope. This means that your PM can plan, discuss with the client, and come up with a plan. You’ve been positive without being manipulated and without being manipulative. This is not an easy discipline but it’s one that I’m still working on now because I default to (a)!
Wrapping Up
I sometimes wish I could go back to 2001 and be the coder then that I am now but part of learning is making mistakes. These days, I try to remember that every decision I make shapes who I’m going to be tomorrow. It’s not like you turn on a switch and then your attitude improves immediately - attitude is like an instrument that often needs tuning.
Technical skills are really important, don’t get me wrong, but without a good attitude, those skills will stagnate, your career will falter, and you’ll get frustrated and isolated. With a good attitude, people will want to work with you, will respect you as a professional, and you’ll find more satisfaction in your work.
I hope you’ve found this chapter interesting. Hopefully some of this advice will help you to be productive, happy and easy to work with. My own book, Deal With It: Attitude for Coders, goes into more detail on some of the topics I have touched on in this chapter and is available for the price of a can of Red Bull!
About Me
Principal software developer at Box UK. Organiser of coding workshop Cardiff Dev Workshop and co-organiser of pub-based tech meetup Unified Diff. Casual game author. Wrote the code for the Million Dollar Homepage. Coder since age 4. Writing down the things I wish I’d known all along!
My blog is at gavd.co.uk and I am the author of Deal With It: Attitude for Coders
Tweet