Yepp, more things I wish I'd known when I started, 3rd edition.
You can find the first article in the series here.
And the previous article here
Beware of the arrogance trap
Arrogance is one of the worst traits a professional can develop.
It's not only about how it affects our relationship with other people, but that's also worth considering.
Arrogance by itself makes you a worse professional. If you believe yourself to be more proficient than you actually are, you become complacent and lower your guard. If you can't do anything wrong and your solutions are always the best, you stop thinking objectively about the quality of your work. This can lead to some of the worst habits in our profession, like:
- Why should I write tests if I know my code will not fail?
- Why should my code be reviewed if it's always awesome?
- Why should I implement this feature if I know better than my customers?
- Why should I use those tools if my programming language of choice is the best thing ever?
Sounds like someone you know?
Being humble is almost a superpower in this industry. You recognize your limitations and put extra care in your work, and as a result, the quality of your code goes up. You can listen to criticism and learn from it, instead of resenting people for trying to help.
A humble professional has a better perspective and can think about himself critically. Cultivate humility, even if it's only for the professional and personal benefits it carries.
Feel comfortable with failure
After years of being told that failure is a bad thing we should avoid at all costs, it's not a surprise that we all feel a strong aversion towards it.
In the real world, being ok with failing can make the difference between a great career and a bad one. In practice, that fear of failure always works against your best interests. Remember that project you wanted to try but were too afraid to start? Well, it could have been one of the most important milestones of your career. Even if the project had failed, you could've learned important lessons and skills.
Trying things outside of your comfort zone is important if you want to grow professionally. As we mentioned in a previous article of this series, one of the best ways to improve your technical skills is working on projects slightly above your current capabilities.
Being ok with failing requires a lot of emotional maturity and humility, and the sooner you develop this trait, the better. A cool side effect is that it affects the way you write code: it makes you program in a way that makes failures evident during development. And we all know that the sooner our code fails, the better. This gives you the opportunity to find and fix issues way before they hit production, increasing the quality of your product.
This is related to defensive programming.*, an important approach we should use more often.
Use Parkinson's law in your favor
There's a thing called Parkinson's law:
Work expands so as to fill the time available for its completion
It's not a law like gravitation or Ohm's law, but a piece of insight about how humans handle work in relation to the amount of time given to complete a task.
It happened to me at university. Like in most places, some terms were harder than the rest, and some were easier. I always wondered why I never felt a difference in the amount of free time I had available from term to term. Well, Parkinson's law: On the toughest terms I was super efficient and hardworking, and on the easier ones I slacked off much more.
How can you use this to your advantage?
It's easy, create artificial deadlines and respect them. We tend to work much better when there is a pressing deadline. It doesn't matter if you are the one who sets it, as long as you respect it and push yourself, your productivity will go up. You could keep some sort of activity registry and offer yourself rewards only if you complete things, but I believe discipline by itself yields the best results.
Next time you wonder why it takes you the same amount of time to complete the easy tasks and the hard tasks, ask yourself if it's because of Parkinson's law.
Oh but I also knew all these things.
It's ok, maybe in the next article you'll find something you didn't know yet.
Thank you for reading, I hope you learned one or two new things or at least got something new to think about.
What to do next:
- Share this article with friends and colleagues. Thank you for helping me reach people who might find this information useful.
- Read the next article in the series.
- Chad Fowler elaborates more about this topics and offers some really good advice in The Passionate Programmer. This and other very helpful books are in the recommended reading list.
- Send me an email with questions, comments or suggestions (it's in the About Me page). Come on, don't be shy!
