I recently read a blog post that is a satirical look at how to gain a reputation as a guru programmer by converting code to your own code and making it hard for other programmers to get their work done. It’s called 3 Simple Rules That Will Make You a ‘Superstar’ Developer and it’s very tongue in cheek.
It outlines 3 simple rules to be a superstar programmer.
Rule 1: Write lots of code. i.e. Rewrite large amounts of the codebase to your own code since you will be more productive fixing bugs and others will have a harder time.
Rule 2: Write your code quickly. Get things done fast. Don’t worry about introducing bugs that are hard to find, but don’t introduce trivial ones.
Rule 3: Don’t take time to document your code. It takes time and others will be able to understand your code better.
This might actually work well in medium/large companies with closed systems. This strategy would work great at my first job out of college. If no one could touch my code but me, I would be king.
This kind of thing is exactly why open source is so great. In open source this strategy doesn’t work because the success of the project depends on how many other developers you can get to work on it. And your reputation depends on the cleanliness of the code base.
So I’d like to propose how to actually make yourself a 10x developer.
- Get out of your current job. If you have a job anything like the above. Get out and get out as fast as possible. You are wasting time spending most of your day in an environment that will not allow you to grow. Get out. I can’t stress this enough. Environment is VERY important.
- Read lots of code. Preferably other people’s code of good reputation. You need to read lots of good code to understand how to write good code. It’s that simple. Understand why a particular implementation is convenient or fast and why other’s are slow or not as convenient for the problem that is being solved.
- Read lots of documentation, blogs, articles and stay on top of emerging trends. Understand what other developers are talking about and why. Your options are so much broader when you know what other projects to look at and what to research when presented with a hard problem.
- Write lots of code and work hard. Everything takes practice and writing code is no exception. Knowing in your brain how to write code is not the same as doing it. I know how to hit a baseball but that doesn’t mean I CAN ACTUALLY hit it, for real, let alone hit a homerun. Write a lot and preferably public code. You won’t get much of a reputation with closed products unless you did most of the work on a product that is widely used and that is publicly known.
- Don’t complain when things don’t work. If something doesn’t work it’s likely your code that’s causing it. Even if you think it’s not and complain when something’s not working it’s very embarrassing when it turns out that it was your code that was the problem that you have been complaining about all day. You won’t make friends by complaining.
- Go to programming events and conferences. Events with other programmers is very rewarding. A big problem with working hard is it’s hard to stay motivated. Other programmers commenting on work you did can be very motivational and give you lots of ideas. Also, other programmers can be introduced to you and your work and you can get a feel for what other people are using to solve problems. Don’t assume someone doesn’t know what they are doing. Many times they surprise you with something you didn’t know about.
Ok, that’s 6 things. Notice that only one is writing code though you’ll need to do that a lot. On a typical day I probably spend about 40% writing and 60% reading. Knowing a lot about other projects, ways of writing code, algorithms, and programming methodology will help you a lot (though not right away). Learning programming is a lot like learning another language (which I also have some experience with), there is a large sunk cost and it takes a lot of time to get to a level of fluency.
That’s it. Let me know if you have any comments!