I have a great
day job, and I am certain it is not possible to find a better work
environment. It is the type of job developers dream of. The software is
interesting and challenging. My colleagues are among the smartest people in
the world. We are respected in our field, and I feel we make a small
difference in the market, and, well, that's why I got into this field in
the first place.
We've been very successful with what we've done in past 5 or 6 years, but with
success comes change. As companies grow they have a responsibility to their
owners, customers, and employees. It is a complex ecosystem. It isn't fair
to take unnecessary risks with software that directly affects the lives of not only all
my fellow employees, but many of our users as well. As with many technology
products, we've opened up markets that simply didn't exist before. For us that
includes one and two person shops consulting to huge corporate and government customers. We provide
the tools they need to do their job. If we didn't deliver a competitive
product, those who have been most loyal to us, would suffer the most losses.
It is my responsibility as an employee to do what is best for the company.
Change is continuously getting more expensive for our software. Every change
needs to be backward compatible with software we developed 6 years ago. Every
change must go through QA, as changes can not negatively affect other aspects
of the software. Marketing and support must understand how the
change affects our current and potential customers, and our documentation must
be updated.
As you mature as a developer, the most
important lesson you learn that can not be taught by any CS program is
that it is nearly impossible to under estimate the cost of change. I can not emphasis this enough.
Change is expensive, and you only learn this after years in the trenches of commercial
software development. If I do not respect the cost of change, I am simply
not doing my job as a senior developer on the project. Understanding the cost
of change and relaying that to management is one of my most important functions.
So here lies the conundrum for both developers and software companies a like. For companies,
the inability to change often comes at a disadvantage in the market. Change
is far less expensive for smaller companies, which are not required to generate
significant and consistent revenue. So if a feature is required by the market,
it is likely that smaller company can afford to implement it before the larger.
The smaller the company is, the less it has less to lose. Ok, ok, yes this is an aspect of the now classic
Innovator's Dilemma.
But you really have to experience it to believe that it is true.
Good developers tend to be highly creative types. We like to try out new techniques,
and investigate technologies before others see them as important (hell there are a lot
of people that still see blogging as hogwash, while we know they are wrong). There is a thrill
in doing something new, but the thrill often involves a lot of risk. The risk that the technology
just doesn't do what we expected (as with a new programming language). The risk
that the market doesn't evolve (typical .com problem). And the risk that the software
just won't work, even if developed with proven technology. These risks often
can not be accepted by companies which must deliver consistent revenue.
The last point is the most difficult for us developers to accept. Why we all
have the utmost confidence in our skills (a requirement to maintain your sanity in this
industry), for those that must decide to invest in a project, there is the non-trivial possibility that
the software won't work, or it won't work in the time frame that the market demands. If
a change or feature doesn't get approved, it often isn't because that change or feature
isn't innovative, it just isn't clear to management that the change will produce
a reasonable return on investment, and your time is an investment, whether you see
it that way or not. Also the time invested also has opportunity cost which might
be better spent on a another project.
So the conundrum is, "How do I do the best job possible as a software engineer,
while maintaining my sanity and being true to my inner creative side." For those of us
that can swing the time, the answer is simple: take on a side project. Almost all the
best developers I know do something on the side. This might include writing articles for
technical journals, attending
user group meetings, acting as a
member of the C++ committee,
or working on an Open Source project. My side project is writing HTTP security software
(ok and blogging). This type of software makes no sense for my employer to pursue, as it
wouldn't be an obvious best use of their time, nor do they have the marketing channels to sell such a
product. And that's what makes it interesting to me. It fills a gap in my personality, and
it doesn't compete against my day job.
I am not alone here. Look around at the developers
you most respect. How many projects are they working on? I suspect you'll find they
have something else going on, as all the best
developers crave alternative outlets for their skills. So from a fellow software developer,
take my advice: never sign a contract that prevents you from working on side projects (regrettably
I once signed a contract that basically said my employer owned my thoughts (I don't know about
you, but those are worth a lot to me)), and if you have the time, take up a side project.