The Self-Taught Programmer's Guide to Working in the Corporate World
I've been programming since I was in Junior High and it has become the single major constant in my life; My interests sway from one thing to another in every other part of my life, but programming is the one thing that has always been there. I am now 26 working on a team of 4 developers. I've worked in an enterprise environment for almost three years now and I've learned quite a bit. I decided to put together a list of tips for other self-taught developers who are passionate about code and are curious about the corporate world.
Don't expect to learn a lot of new tech.
One of the things that surprised me when I first began working in the corporate world was the fact that I knew more than I realized. I had been programming on my own for several years. I was extremely nervous about working with developers who all had computer science degrees and were used to working collaboratively. After being hired I quickly realized that not only was there very little tech for me to learn, but I already knew more than a lot of my team. This is clearly subjective and may not be the same experience for everyone, but thinking back it does seem to make sense that a naturally passionate self-taught developer might be more educated and/or more up to speed with the latest and greatest tech than others who simply do it to put food on the table.
Despite being a surprisingly competent member of the team, there were a few things that I had to brush up on simply because of the collaborative environment. Working as a solo developer for so long I never really took the time to properly learn a version control system. In hindsight I realized that I was totally missing out. Even a solo developer should be using source control. I was also somewhat unfamiliar with using a issue and time tracking system because on my own I never needed to do any of that. Clients would email me anything they needed and tracking my own time was easy using nothing more than Google Calendar.
Don't expect others to share your passion for code.
For many years I thought that passion was a requirement for being a programmer. I guess I just assumed that this stuff was far too complex and boring for anyone who didn't completely love it. It turns out that was bias on my part because I was unable to imagine myself writing code if I thought it was boring. In reality there are many people who write code for money, and that's about where it ends for them. For some, programming used to be a hobby but the corporate world quickly beat the excitement out of them. For others, it's always been a means to an end and nothing more.
Regardless of why, the fact is that I have only worked in the corporate environment with one person who truly had the same level of passion for development that I do and who wasn't already someone I knew outside of work. That's not to say that I haven't worked with some awesome and super intelligent people, but even among those I have come to respect I don't know many who care quite so vehemently as I do. There are some that are better than others, but so far in my experience true passion has been a fairly unique trait. In fact, among the people I've worked with I'm the only one that enjoys maintaining a programming blog. It is key to realize this fact early on if you don't want to suffer a series of disappointments. Finding out that few others cared as much about code as I did reminded me of Junior High; I remember putting together elaborate programs and games and showing them to my parents only to have them go "that's nice sweetie" as if I was a kindergartner who just drew a really crappy picture of a house and they're trying to be polite.
Just like when my parents didn't really understand just how much work went into the things I was showing off, it's important to realize that it's not their fault. You can't expect people to see through your eyes and understand how much of yourself you poured into such a technical project. You will work with people who the most creative thing they ever did was go to Google and copy a code snippet from someone's blog. You have to learn to accept that those people just don't see things the same way that you do and probably never will. It sounds really condescending, but I've had to work really hard to not feel or act like a primadonna. When you're the only one in the office who truly lives and breathes code it can be extremely easy to feel superior to others you work with. This effect is exacerbated by the fact that since you do retain a lot of knowledge you will quickly become the go-to guy for questions. This is both flattering and annoying depending on the day. It's extremely important that you work really hard to remain humble if you don't want to look like a tool.
Micro-management is commonplace.
You might think that because what you do is highly technical that you would be given a lot of breathing room to do what you do best and that you will be implicitly trusted as an expert in your field. This may be just a really dumb assumption on my part, but I was fairly surprised when the opposite was true. I've since come to find that bikeshedding is commonplace in the software development industry. Programmers like to write code because that is what they enjoy. Programmers seldom want to manage a project and/or teams of developers. Because of this I've found that managers of IT shops are almost never competent developers themselves. As you can imagine, this creates a dividing line between the developer and the rest of the company.
A reliable programmer like yourself probably knows how to manage their time appropriately to meet goals they set. Don't expect anyone else to see it that way in any corporate environment, not just software development. I've learned that there are two types of managers. The first is the type that recognizes it is her job to manage a highly skilled team. This type of manager will get to know the team, learn what each member likes and what they are good at (those two traits almost always coincide), and she learns to depend on her team when making managerial decisions, consulting one or more of them who she knows will have valuable input she can depend on.
Does a development environment like the one I just described sound like a great environment to work in? It is! I've had a taste of such freedom and trust during my time in the corporate world, but sadly, in my experience the second type of manager is far more common. The second type of manager is the type that thinks she is queen of a small village in need of guidance. This type of manager almost never recognizes the strengths and weaknesses of her team. Rather, this manager maintains distance from her team; she only comes out of the royal chamber to announce changes in kingdom policies and hang the occasional peasant for not plowing the fields fast enough. Once in a while, when the natives get restless, she will stroll through the village and pat people on the head to win back their favor before quickly retreating back to the castle.
I'm sure you can imagine that the managerial style I just described can be a royal pain in the ass. However, unless you are brave enough to overthrow the queen, it's just something you will have to adapt to. Things can always be improved and a passionate person like myself is always in a hurry to execute that change. If you're lucky enough to have a manager like the first one I described then you are free and likely even encouraged to express yourself as much as possible. If you are not so lucky then try not to feel too bad because places like that are hard to come by. Instead just realize that there is a small game you have to play in order to avoid the queen's wrath, which brings me to my next tip.
Constantly trying to improve the village is a no no.
In the previous tip I described two managerial atmospheres you are likely to find in the workplace. If you're one of the lucky few to work in a totally open and agile environment then this next tip doesn't apply to you.
A manager that is cut off from the team, no matter the reason why, sees things much differently than the rest of your team. All she sees is whatever happens to stray close to the castle. Unfortunately, when you cut yourself off from the world the only things that are likely to come across your desk are negative because nobody dare disturb you unless it's something really important. The really important things are almost always negative because they are the types of issues that usually require managerial input for how to proceed and solve the problem. In my experience this type of manager has a very negative perspective with regard to her entire team because only the flaws ever cross her desk.
This type of manager often believes that she is the only competent person in her department and that it is her job alone to keep everyone in line. Because she does not understand the collaborative resources she has available to her she will make uneducated decisions for the whole group. Once a person has surrounded themselves with such a bubble of ignorance it becomes a very delicate political game for anyone trying to pierce it with suggestions for improvement. They believe they are solely responsible for making all decisions that affect the team, delegating responsibilities to the team, and micromanaging their time to ensure it gets done. Any developer worth their salt knows that this process has the opposite effect and actually hurts the software being produced. Unfortunately this lack of trust in the team means that any suggestions you try to bring to the table will often be rejected out of hand. It makes for an extremely rigid atmosphere wherein everyone is just trying to maintain the Status Quo rather than create great software.
Unless you're willing to keep looking for greener pastures then this is one of those things you will just have to accept early on and try not to let it eat at your soul. Office politics are not at all unique to software development. You can keep looking as long as you are comfortable but the cold reality is that it's really hard to see these issues before you accept a job offer. If you do end up in a monarchy IT shop don't fret too much; you just have to be a little more clever about the way you convey information. When I have an idea for improving or solving a problem I find that describing the problem in such a way that there is really only one obvious solution is effective at making others think the solution was their idea. You just have to be really good at defining the problem. Narrow down the variables until a singular ideal solution is staring them in the face. I could write a completely separate blog post on tips for how to play the political office game, but for now just realize that effective communication can be a delicate process at times.
Don't expect old dogs to learn new tricks.
When I was hired there were several "old dogs" who had been around the block a few times in their day. They were great developers and I'm sure they had a lot I could have learned from them if they were willing to talk instead of just bark. If you come into a team with people who have been there a while don't expect them to jump for joy when you suggest change, no matter how big or small. Keep in mind here, there are two sides to this coin. On the one hand you are coming on board and immediately start seeing all the ways in which you could contribute and help to improve things. On the other hand, put yourself in their shoes; you've been working at the same place for five years and you've learned quite a few things. You're already familiar with the politics of the company and likely already know how to play the games. Some new person coming in who immediately wants to break the Status Quo you've worked so hard to maintain isn't going to make you feel very much excitement.
I'm not saying that you should stop trying to improve things and just suck it up by any means. All I'm saying is that things should be done tactfully. Play the game for a while, do what you're told and do it well. Show them that you can do what is asked of you and do it spectacularly. Be innovative within the confines of whatever freedom they have given you. Show them that you can be a team player and are willing to learn how to fit in the way they are used to. Show them that you respect them and go to them with questions. You'll be surprised how far that gets you with others on the team. Once you've earned some respect on the team you can start stepping outside the box a bit and test the waters. Just don't make snap judgments or invest too much emotion into your ideas. If one of your ideas gets shot down try not to take it personal and realize that there are plenty of ideas from others that you'd probably shoot down as well without meaning to insult the person who had it. I've made the mistake of taking it personally a few times before and it only served to supremely piss me off for the rest of the day, which is silly and pointless.
Fulfill your passion outside of work.
I know this probably isn't what most people want to hear, but if you're like me then you really want to make amazing software because you really enjoy it. Sometimes, for whatever reason, the work atmosphere is not conducive to creating amazing software. If you have a burning desire to write awesome code then consider doing it at home on your own time. One of my favorite things to do is to write open-source software at home that would be useful in the workplace and license it with an MIT license. Then I'm free to write the code however I choose on my own time, but I can then also use the software on the job to solve an interesting problem.
Writing code at home, while taking up more of my personal time, gives me the freedom to create cool things without having to worry about a manager telling me I'm spending too much time on it and it's costing the company too much money. A lot of companies frown on you "working from home" for a variety of reasons (reasons I don't agree with, but that's neither here nor there). By writing open-source software at home you're not working from home at all. You are simply writing software as a hobby at home that just so happens to solve some interesting problems at work. From your manager's perspective you simply used an open-source library to solve a need at work that would have taken a lot longer had you had to write it from scratch. This also has the added benefit of contributing to the community of open-source software. Others may find that the library you wrote also solves a problem they have been having as well.
We developers use libraries written by other people all the time in our work. Using a library you wrote on your own time is no different. Of course it would be nice to be paid for the extra effort you put forth but that's not always in the cards. For someone who isn't passionate about writing code, it probably sounds like a terrible idea to write code for free. Maybe it is, but for someone like me who loves to program it's just something I have to do to satisfy my creative desire to create something awesome.
Be rational.
One of the most common themes I've seen play out in the office is Chicken Little. It is a simple fact that things go wrong in an IT shop. Believe it or not this surprises some people. Even if you have amazing test suites and extremely detailed documentation and deployment procedures stuff will still go wrong. I completely understand how, as a user of software, when one or two bugs occur in the application I'm using I immediately lose confidence in the software as a whole. What I don't understand is how the developers who wrote that software can do the same thing. As an end-user I don't understand what is going on behind the scenes of the application. I can guess at how some things were accomplished but unless I got to see the source code I would never truly know. The only thing I do know for sure about the application is that I've already experienced a few unhandled exceptions. It doesn't take long after that for me to start imagining what terribly messy code could be living behind that fancy user interface and I lose confidence in the software.
When I'm writing my own software I know that I take great care in crafting quality code. When I encounter the inevitable bug with my software I never fret because I know I'll be able to narrow down the issue and fix it. I suppose I used to be full of assumptions about other people, but I used to think that all developers were rational people who rarely overreacted to bugs. I was wrong. So wrong in fact, that I was taken completely off-guard the first time I witnessed a member of the team get up and start shouting "The sky is falling! The sky is falling!" A naive person might think that was a unique case, but they'd be wrong. Sometimes the only thing that can save the day in these situations is a rational person to calm everyone down and focus on the solution. Don't be Henny Penny. When something goes wrong don't start pointing fingers and losing your marbles about it. Sit down and think through the issue, pulling in anyone who you think might be able to help.