On the first day of my first professional job, an experienced colleague gave me a piece of advice which has served me well for many years:

"Admit it when you don't know the answer"

Simplistically, this works because it prevents you from getting in too deep when things get tough. But it’s not only that - there’s more here than meets the eye. Below are three of the hidden benefits that careful application of this adage can deliver.

Ask Questions on Stack Overflow Early

Some folks hate posting on Stack Overflow. I love it. But a good half of my posts never make it to the submit button.

Why? Because frequently, the very act of crafting a coherent, to the point, detailed-enough question makes you re-visit your progress to-date, to the extent that the “obvious” solution which you knew was staring you in the face all along finally reveals itself. It’s because of this that I’ll ask a question on StackOverflow if I’ve been stuck on something for more than half day.

Why Stack Overflow specifically? Because it’s built up a culture where badly asked questions are at best edited by others into what they should have been, and at worst publicly humiliated, all of which is attached to your public profile. It’s the very threat of this that makes me do a good job. It’ll make you do a good job too.

And aside from the benefit of solving your own problem, it means you know the questions you do post are genuinely hard ones - hard for you anyway.

Do TDD, and do it Right, for the Right Reasons

TDD is primarily a tool for combating fear. Don’t believe me? Read Kent Beck’s foreword to his Ur-text Test Driven Development By Example. And where does the fear come from? From trying to put too much in your head at once, and then to keep it there while you design, implement and refactor.

And Kent’s right. Admit it. When you’re coding, how often do you get the “brain full” feeling because you have to keep so much up there in L1 cache? In TDD, the tests are there so you can offload loads of that into the code, freeing you to do the creative analysis and thinking, to find the best solution.

But to admit it you need to face the fact that perhaps you’re not as clever - not as good a developer as you think you are (Luckily for me I had a head start in this area; I never thought I was a good developer). Don’t believe me? (Re-)read Kent’s book and realise how much he talks about his limitations and shortcomings. But he’s a great developer right? He’s written all these books and worked on all these systems right? Think about it…

Shout When Something is “Too Complicated”

Finally, lets take this specific lesson one step further. How often have you picked some task up - a bug, a feature, any kind of task in fact, when you’ve had to admit to yourself that “the code / design / other input I’m looking at is just too complicated. I just can’t grok it at all.” If we’re being honest, and unless we’ve been very lucky I’m guessing this happens every now and then, or perhaps more frequently.

My experience is that we as developers use this emotional feedback simply to beat ourselves up. I did, for years and years. However, as I’ve developed, I’ve realised it’s one of the most useful pieces of feedback you can gift yourself.

Why? Because we’re always told that simplicity is the Holy Grail of development; to be aimed at and prized above all else. Furthermore we’re told that to get to this Celestial City we have to typically work through the Slough of Unnecessary Complexity. And yet we reward complex solutions - we fete those who create them, and throw laurels at them when they mount a Herculean effort to fix a bug in the face of which many lesser mortals had failed.

How do we combat this? We combat it by trusting our inner voice - the feeling that “this is too complex” and “I’m having trouble holding all this in my head”. Perhaps if we owned up to these feelings, and even better vocalised when we found something “too complicated”, we’d start off something from which not just ourselves, but others would benefit. I mean, who amongst us doesn’t want to have been responsible for a “simple” solution?

Kill your Ego

All these sound like brilliant ideas. Lets go! But something will stand in your way - your Ego, and it’s associated fear of being knocked. Get over it! These are only the beginnings of the benefits that you can realise if you give yourself the gift of admitting when you’re not feeling too bright. Others riches will soon be yours too - colleagues will want to work with you more, you will learn from them and they will learn from you, and freed from the tyranny of self-doubt, you’ll be plugged into the mainline of simple elegant design and be reaping the benefits. Let go! Kill your ego!

We’re Hiring

Like this post? Think you’re the kind of person who’d thrive in the environment where you’re encouraged to challenge the status quo. Know you’d love to collaborate with others, create simple and elegant solutions to customer’s complex problems? Drop us a line ‘cos we’re hiring.

Join our Java team

If you like the sound of what you've read and would like to join our team, we're hiring!

Find out more about working with Capgemini

Comments