This is the second part of my Programming lessons I wish I knew when I graduated series in which I discuss how much I suck at programming and some of the lessons I’ve learned on the path to sucking a little less. You can read part 1 here.
4. It’s OK to be wrong
A computer lets you make more mistakes faster than any invention in human history—with the possible exceptions of handguns and tequila.
Mitch Ratcliffe
School tends to be all about getting the right answer: tests, homework, projects, and grades are all about doing things “correctly”. This may seem perfectly natural until you realize that success in the real world requires much more than just “not being wrong”: you need creativity, risk taking, curiosity, exploration, innovation, and trial and error. The focus of schools on solely black and white, yes/no style evaluation is killing creativity and leaving students unprepared for the real world.
The greatest mistake you can make in life is to be continually fearing you will make one.
Elbert Hubbard
You need to be fully aware that you are not perfect. Your programs will have bugs, projects will always take longer than expected, your architecture will not scale, your designs are full of anti-patterns and your code will have to be thrown away and re-written. This is OK. Do not be paralyzed by a fear of error. In the world of software, you have to move fast and break things.
Pro tip: embrace the fact that things will go wrong. Deal with it by learning to (a) be humble, (b) take ownership for your mistakes, (c) learn from them, and (d) do better next time.
5. DIY
The best way to predict the future is to implement it.
Alan Kay
For a long time, I had assumed that my job was to do whatever my boss told me. If I got assigned to work on project X, then that’s all I would do. If I saw something outside of X that I thought the company should be working on, the most I’d do is complain about it at lunch time: “I can’t believe we’re using technology foo instead of bar!”
Then I joined LinkedIn and I started participating in the monthly hackdays: a company-sanctioned way for me to work on projects that had nothing to do with my current “project X”. I loved it, won a bunch of hackdays and even got some of them live, such as the Resume Builder.
LinkedIn Hackdays are amazing And then something really interesting happened. I started taking on side projects on a regular basis, and not just during hackdays. I wanted to give LinkedIn engineers a place to talk about our work, so I created the LinkedIn Engineering Blog; I noticed that the strict visibility and typing rules of Java made automated testing and mock objects difficult, so I added the ability to write our automated tests in Groovy; I wanted to share the fun of hackdays with engineers from all over the valley, so I got a team together and organized LinkedIn’s first public hackday. None of these projects had anything to do with the “primary” projects my boss told me to work on. But once I took the initiative to do them, I got support, praise and encouragement from my boss and nearly everyone else.
Pro tip: if you work at a half decent company, your job isn’t “to do what your boss says.” It’s to apply your skills to make the company as successful as possible. If you see a significant problem or opportunity at work, then most likely other people do too. Don’t wait for it to magically take care of itself. Go out and just do it yourself. You’ll be amazed by what you’ll learn, how supportive co-workers and bosses will be, and how fulfilling a job can be when you’re working on exactly the things you’re passionate about.
6. Be heard
Write to be understood, speak to be heard, read to grow.
Lawrence Clark Powell
Let’s try an experiment: I’m going to ask you two questions and all you have to do is take note of the first answer(s) that pop into your mind. Ready? Ok, here goes:
- What is the best software company in the world?
- Who is the best software engineer in the world?
When you read the two questions above, a few names probably popped into your head. What’s interesting to note about this is that only a few names popped into your head. There are countless software companies and engineers out there creating amazing software, but you inevitably think of only a small handful. So, you want to know why you think those few are the best?
The great software companies and engineers of the world dedicate an enormous amount of time and effort to telling people that they are the best. This is done using 3 primary tools:
- Talking: conferences, meetups, lectures
- Writing: books, articles, blogs
- Showing the code: open source projects, code snippets, tutorials
I’d bet that every great software company and engineer that you thought of has written a book (or the book), has a popular blog, has given numerous talks, and/or open sourced tons of code. You’ve probably seen their name so many times that it’s no accident that it’s the first one to pop into your head when you think of greatness. What will pop into your boss’s mind when someone asks him who is the best engineer on his team?
Pro tip: if you want to be a great engineer, it is NOT enough to merely write good code. You MUST tell others about it. This holds true at all levels: from the guy in the cube next to you, to your boss, to the CEO of the company, to other programmers all over the world, the only way they will think you are a great programmer is if you consistently tell them you are. And the only effective way to do that is to use the 3 tools above: talk, write, and show off your code. This is the way to get recognition for your work both inside and outside of your company.
It’s a long journey
An expert is a man who has made all the mistakes that can be made in a very narrow field.
Niels Bohr
I’m still not a very good programmer. I am keenly aware of many areas where I am weak; there are countless others where I am totally ignorant. But being aware of this means I’m miles ahead of where I was some 5 years ago, when I first stepped out of school. I still have a very long way to go. To steal a phrase from Jeff Atwood’s delightful Strong Opinions, Weekly Held, I’m merely a “rank amateur seeking enlightenment”. I hope this series of posts has been useful to the other amateurs out there and helps you on your own journey.
Yevgeniy Brikman
If you enjoyed this post, you may also like my books. If you need help with DevOps, reach out to me at Gruntwork.