It’s amazing how small things in a work environment can make the difference between a job I look forward to on Sunday night, and a job that makes any time too soon to get up. That statement is actually incorrect. It is a few very big things that cause this difference, but they are subtle and abstract. They manifest in small ways that contribute to the destruction of motivation. It is skillful and subtle demolition of motivation that makes large enterprise-y company into a soul-crushing beast that takes in bright, enthusiastic developers and spits out 9-to-5 drones. Like frogs in boiling water they usually don’t understand what or why it happens.
This is the story of how I find my motivation evaporating at a large enterprise software company.
A convenient way to break things out into categories is to use Daniel Pink’s elements of motivation. These three factors are mastery, autonomy, and purpose. For mechanical tasks monetary or equivalent rewards work well, but for creative or cognitive tasks, higher monetary rewards can actually reduce performance. To get high performance for these tasks, people need non-monetary rewards, and that is where these three factors come in. He has written extensively about this in Drive. To get a quick summary of it you can watch the TED talk (18:37) or a longer talk given to the RSA (41:22).
Purpose
Purpose is the feeling of inspiration that comes from writing code that you care about. It is doing something you can be proud of and that makes you feel good in a moral sense. For me, this is mostly fulfilled by writing quality code that solves interesting problems. The problems themselves are interesting to me, even if the application is unclear, limited, or doesn’t affect me. I want to write code that betters me and that other people can build on and learn from.
However, the code I have seen so far is not something I want my name on. In fact my eyes have been opened to how bad code can be and still pass for a professional and world-class product. It is hard to go home happy at the end of the day when I am embarrassed to tell my friends what I work on, and when I don’t want to show the application to anyone because of all the bugs and compromises I had to make. When I cannot give a good technical reason why things were done the way they were I find myself afraid of questions about our design choices.
Unfortunately, I find that a lot of the work I do is constrained by the lowest common denominator. The code has to be written so that it isn’t too different from the worst code so that the worst developers don’t get too confused and the poorly designed system doesn’t break. I spend most of my time trying to work out poor design decisions in the past and not being able to try interesting things and really solve the hard problems.
I firmly believe that if a programming task isn’t hard then it should be automated. Code can be written so you don’t have to repeat yourself, so that it is DRY. All code should be written such that future additions have less and less work required until all that is required to specify only the items that are unique to this new feature. For example, a new button in the navigation bar of a web page should not require modifying every page to add it. It should not require copying the layout to a new page. It should not require copying all the permissions code. It should not require writing all the database query setup, connection, and tear-down all over again. It should only require you specify a new menu item, specify what happens when that button is pressed and when it is visible, and then write only the code that is absolutely unique to that page.
Getting to this point is an asymptotic process. You can’t get there instantly, but ever time something is duplicated, it can be factored out. When pattern gets used it should be abstracted. As the code progresses, it gets cleaner.
At this corporation I find that we have so much duplicate code that at least half of our time is spent copying code and modifying it slightly for the new code because that is how it is done in 100 other places and there isn’t time in the roadmap to change all those 100 places the code is used, there aren’t enough QA resources to make sure all those 100 other things still work, and there are 20 other developers who might get confused if the code is changed from the way they are familiar with.
The corporation becomes afraid of change and the lack of change causes the cost of change to increase each time refactoring is skipped in favor of the quick but dirty fix. These corporations accrue and accrue technical debt to the point that they paralyze themselves. And when you cannot create anything new and cannot even do a good job, you can’t create anything interesting and there isn’t much you can take pride in.
So why keep working if I’m just going to feel guilty about it later?
Mastery
Mastery is the desire to get better at what you’re doing. In me it’s a desire to learn and try new things. I want to learn new ways of doing things, try new things, and work with people who will force me to get better at what I’m doing. I want to feel that at the end of each project I have done something that I would not have known how to do before the project. An interesting problem on its own can motivate me to work harder than I will for money.
I can’t even tell you how many hours I’ve spent experimenting with Rubik’s Cubes and similar puzzles. I take it as a personal challenge to figure these things out, and now that I know some of the basic principles from my 3x3 cubes, I refuse to look up solutions to similar puzzles. I actually make the work harder because I will learn more.
I spend hours and hours programming for fun in my free time. Most of that time is spent trying out new open-source technologies, learning new programming languages, creating web-sites, and working on open-source projects. None of these things have direct monetary rewards for me, but I love getting better at programming and learning new things. The total hours I spend work out to at least a part-time job.
With our code-base so horrible and our inability to do anything new, I cannot explore anything new and I cannot find new ways to improve the code. Improvements are almost frowned upon. I start to worry that my coding will become worse because I will pick up the bad habits I have to employ because I’m not given time to fix them. All that motivation that drives me to work hard at home or in school is lost when I cannot work on something that I think will better me as a person.
I worry that many of the developers at this company are not particularly talented. For example, I can only think of a handful of engineers who I know to program outside of work hours. Most of them are not proficient in any language other than Java, except maybe JavaScript. When I mention languages like Ruby, Python, Scala, Clojure, or Haskell, most have never even heard of them let alone are able to have a serious conversation about the trade-offs between different languages. Many of them don’t seem to be particularly well trained in terms of algorithms and theory. I asked one engineer what their favorite sorting algorithm was and they responded, with seriousness, that it was Bubble Sort. When asked why they responded that it was easy to implement. These are not traits of people who are looking to improve. They do not question the way things are and seek ways to make things easier in the future. This prevents me from being able to collaborate on a high level. When I suggested an improvement to one of our large applications, another engineer told me that we should instead try to keep things consistent with the other groups, so I should drop it.
I can’t converse with these people to learn. I can’t have a debate where we both learn something new. I can’t have them point out a way in which things could be done better because most of them aren’t interested in improving themselves or the code base. Smart people want to be surrounded by other smart people because they want to be understood and they want to have to work to understand what their peers are saying.
How do we end up with all these people? There are two factors. First is that quality people are not hired, because the primary goal is to meet deadlines and that means hiring people who know a few specific technologies and can start writing code towards this deadline quickly instead of hiring people who will take longer to get up to speed but contribute higher quality code in the long run. The second is that people who are happy in a job tend not to leave, so those who want to do things differently will have left and found another job, and those who remain are happy with the system and not terribly worried about changing it.
Being unable to converse critically with my peers and unable to try interesting things within our work really doesn’t allow me to learn anything new at work. Instead I find myself writing boilerplate code work around previous design mistakes. I don’t feel like the organization is really interested in making a large effort to get things fixed. Instead of stopping to fix the problems we have, we have promises that things will be fixed at some indeterminate time in the future. For example, when I joined it was already a joke that things would be fixed in the Big Rewrite and a joke that Big Rewrite would be coming “soon”. This gives the impression that lip-services is given to the idea of improving, but the actual effort is deferred indefinitely.
So why keep working when you’re just going to have to redo it later because you couldn’t do it right the first time?
Autonomy
Autonomy is the feeling that the decisions I make matter, that my decisions are respected, and that I’m given the power to make decisions.
This ties in closely to the mastery comment. I feel like this company does not really value original contributions. People are not very interested in trying new ways of doing things, and are more interested in keeping things as homogeneous and conceptually simple as possible even if that means more complexity, bulk, and bugs in the code. The structure of the code makes it hard to try anything interesting because the cost of change is too high.
This problem also comes up in planning and scheduling. I have the feeling that when suggestions are made for things that need to be done, often they are overruled by the desires of the project managers and the fully-booked road map has no room for what the developers want because management has already filled it.
For example, when I enthusiastically complain that portions of the code need to be rewritten sooner rather than later, I am told to wait an indefinite amount of time for the rewriting project to be placed in the road map when I would rather take the time to do it right now. This leads to many poor work-around jobs that accrue technical debt. I found a portion of the code, that was fairly small and is very poorly written. It hasn’t been touched for about five years and sorely needs an upgrade because the infrastructure can barely support the modifications we are making. I advocate taking a time out on the new features to refactor and fix the old code, but that isn’t in management’s timeline, so I will have to wait for them to schedule it in, and since the roadmap for the year has already been planned out, maybe we can get it in a year or two. In the mean time, I am told, please work on the projects management has deemed important.
I would rather get things written right than have to fix bugs for the next six months. However, we don’t leave time in the sprints to schedule these things in and we when we come down to the wire (which we seem to do fairly often) the rewrites are pushed out first as management doesn’t see them as as necessary as the developers. I see things that I want to improve. I want to dive in and bury myself in improving these things, but there are other routine tasks that management wants done, so those take priority. It gives the impression that my time is not my own and that all my time at work is to be filled by management with management approved tasks. It is coding as a machine, not as art.
Writing good code also means having the correct tools available. In a large enterprise where the cost of change has increased to the point that people are afraid of it, IT and security groups can be the worst of all. Any IT or security group would rather that everyone just stayed home, because that would make their job a lot easier. They have to make some concessions so that work can actually get done, but the less ground they give, the less work they have to do. This creates a tension between development and support groups, and unless management constantly fights for the rights of their developers, we will be stuck using only the tools and technologies that support will let us have, further reducing my ability to do the best job I can.
So why keep working when I can’t work on the things I find interesting?
Conclusion
All of this can be traced back to a company that prefers stability over quality. The most important thing is not to disrupt the current state of affairs lest the new be worse. The company will avoid potential improvements for fear of potential losses, and has been slowly backing itself into a corner so that the only way to forward is through long, slow, hard work.
I want to do good work. I don’t care about the money or the benefits. I just want to create a good product, create good code, and improve myself and maybe the discipline while I’m at it. If nothing else I would like to improve the average code quality in the world. Give me something to work on and I will do that, but first the company has to get out of the way. If I have the freedom and support to do great things, I will do everything I can to do them. If the company is afraid of that and spends their time micromanaging and imposing limits on what I can do then I’d rather be a homeless hacker than an enterprise hack.
There really seem to be three choices.
- I could live with it, and let my soul be ground into dust. I’d make good money and I would have to satisfy my intellectual curiosity outside of work.
- I can try to change the system and make a difference at this company. This would involve a lot of long, hard work that may or may not pay out.
- I can go work somewhere else that is more in line with my personality.
Life is short. I don’t want to waste my time with a company that won’t change and won’t help me better myself. I’m starting to look at option #3 very seriously.
Oh, and to top it all off, they say they are Agile.