Here is a collection of thoughts about being a successful software person (i.e. software engineer, hacker, person that touches code randomly, designer who codes, programmer, systems engineer, administrator, etc…)
Find your customer.
Making software for yourself is fun, but making software for others is where you start to build your empire of awesomeness. The most important thing, for you, as a software person is to find the customers that you want to make awesome. You want customers that you can connect with and understand, so that you can deliver your best day in and day out. You want customers that will make you feel guilty for shipping crap.
Having any form of apathy for your customers, disconnectedness from your customers, or having a poorly defined sense of customer is a terrible way to live. Make sure that you can connect your work to actual people and how it benefits their lives, then your work will have both meaning and purpose.
Invest in yourself via side projects.
I'm a huge fan of side projects. Side projects are a great way to expand your knowledge of your craft and get a ton of practice in building software. My advice is to always pick something a bit crazy, and go try it. Just try something crazy, and it will be a rewarding adventure.
However, a natural criticism of side projects is that they are a signal that your day to day work isn't satisfying. I don't believe this is absolutely true; I find a great deal of interdisciplinary ideas and successes between both my side projects and my day to day. The problem is more of a social one rather than a technical or life satisfaction issue. The social signal of side projects is hard to ignore, and you need to be smart about it and gauge whether or not it could be a career limiting move. Simply put, do side projects for yourself until you are comfortable sharing (or change jobs when the time is right).
The natural resistance to side projects is “life”; you do have a “life” to live, so staying indoors glued to a project may not be the best life advice. The important thing is to learn balance, and that will be a struggle. I believe that investing early in your career will pay dividends, so it is worth it. However, the thing to keep in mind (which is in many ways very unfortunate) is that you are competing with people that have side projects.
One day, your side project may be your main day to day project. This is the ultimate goal, and the most important part of doing side projects is to find the one true project and to get enough experience to be able to either (a) start a company or (b) join the market leader doing it.
Learn to be creative and inventive.
Is it better to master MySQL or to try to invent your own database?
I'm a huge fan of inventing your own database simply because you will learn more by doing it. Sure you may realize at the end of it that it was a giant waste of time, or that the thing that you invented was kind of crappy, but you will learn many things that will apply to your next invention. Again, this is why I'm a huge fan of side projects. Your side projects are a great way to experiment and dabble in very risky things especially if you think they are interesting.
Now, you should be practical and not try to invent everything. You should focus and invent things that you think benefit your customers or enable you to deliver more for your customers faster with higher quality.
Creativity and inventiveness are like muscles that need exercise. The more problems you overcome by invention, the easier the next problems are. As a bonus, you will understand many of the design choices in the products that you use; this will inspire your designs to be simpler.
Suppose that you disagree with me and you should master MySQL, then what kind of skills do you build when you avoid NIH (Not Invented Here) syndrome religiously? Sure, you master what exists, but have you mastered the unknown? Will you have the skills to take a blank piece of paper and turn it into something amazing?
It's never good enough, so practice being bad to learn judgment.
The more you do and learn, the more you will become aware of. The more you become aware of, the more things you will need to take into consideration. Consider the number of constraints possible when building software: cpu/time, memory footprint, io capacity, network utilization, memory corruption, code size, number of threads, contention, other processes, files, credentials, privacy, security, etc… Getting them all right and perfect is expensive (and there are things that you may not know that you should know which really throws a wrench into achieving perfection).
I hate the term 'good enough', but it is something that I've begrudgingly learned to appreciate as I age. Since I no longer have the time to seek perfection (except on side projects), I practice exercising judgment with bad things. For instance, if your first implementation is O(n^3), then is it bad? Well, sure it's 'bad'; however, what if it finishes 99.999% of the time in less than 1 ms for moderately (and unlikely) large n. Pick your priories that have to be perfect (i.e. security), and then learn to manage the imperfections in your product that aren't as important (i.e. memory footprint).
Measure everything to enable judgment.
Exercising judgment requires things that you can compare. The easiest thing for us humans to compare is numbers. Thus: measure everything.
Just do it.
If you have an idea about how something should be done, then just do it. Whether sanctioned or not, just do it. If you believe it needs to get done, then just do it. If ___, then just do it.
I'm a huge fan of asking for forgiveness rather than permission. However, this can be a risky move, so it's best to be secretive until you have something of value. Even then, if it blows up in your face (due to either technical problems or politics), then you still learned a ton of valuable lessons which will prime you for success later.
It's OK and natural if some days suck, but if most days start to suck, then you are doing it wrong (or… you need to go somewhere else). At the end of the day, you need to have enjoyed a majority of your day.
Build an Empire and Own it.
The product is a kingdom, so learn about every parcel. Pick areas and take ownership (preferably areas that are not already owned and have scary business risk with them). Be the 'go-to' person for the various realms of the kingdom. Make sure that when bad things happen (and they will), then you can ride in on your white horse and save the day.
The natural side effect of this is that you own a piece of the kingdom, and you can start to make long term decisions regarding your parcels. After all, you will be the expert on that region of the kingdom.
Let others tend your Empire.
As you build your empire of knowledge and expand your scope over the product, make sure that you invite, share, and teach others how to tend to it. Hording knowledge is extremely ineffective for both yourself and the company. If you find another empire builder that isn't inviting, sharing, or teaching others, then invade. It's risky for your customers to have individuals having complete dominion over critical aspects of the kingdom; after-all, we are human and we die (or go on vacation).
Instead of complaining, I recommend just fixing things that suck. However, there are situations when that doesn't work (i.e. major architectural shifts, lots of review needed, lots of redoing old things, lots of things that need to get done which requires resources beyond your own fingers and outside your day to day goals).
Things can suck, and they can suck bad. Rarely is anything 'perfect' (see above). An ineffective complaint is “this code all sucks because it isn't functional”. An effective complaint contains (a) the problem, (b) the ideal long term solution, and (c) the short term mitigation/solution.
More to come…
There's not really a finish to this document, and I will add to it as I think of things. For a more proper conclusion, I would like to end on a high note. This field is a very prosperous field if you are willing to work hard at it. In a multitude of ways, we are lucky that people actually pay us to play with computers.