Ask WTF: Learning The Business

This kind of story seem to come up over and over in the programming world. I'd like to add something from my experience working in large development companies.

The first months or so, it's perfectly understandable that a new developer doesn't "get" the application, how it works, or even what it does. The myth of the ninja programmer turning things around, applying a mix of beautiful elegance and sharp efficiency to save the business big bucks, is just that, a myth.

Actually, during this period, a new recruit should focus on one thing only: survival.

Deliver the mindless code, even if it doesn't make sense (or seems plain wrong), but deliver it on time. Do not slack off on your hours, show up (at least) ten minutes early and leave (at least) ten minutes late. You may be the genius programmer who delivers in an hour a day's worth of an average programmer's productivity; but now's not the time for cleverness. Now, I repeat, is the time for survival.

It is also the good time for getting to know (and being accepted by) your colleagues and your direct managers. Coffee/cigarette/you-name-it breaks are important. Do not miss those.

So when do you get the chance to behave like the great programmer you always thought you were? From experience the milestone has always been the same: The next batch of recruits (which in my case has always been around 8-12 months in large enterprises).

As soon as you're not the "new guy" anymore, things automatically change. Not only have you already earned the acceptance and trust of people around you, but you've also seen enough of the code and interacted enough with business analysts. You have much more elements in hand to be creative and take initiatives.

In short, I'd add one thing to this article: Be patient. It's true that you can never see the whole picture, but as time passes, you can definitely detect the places where you can have an impact. Until then, you simply have to turn on your survival mode.

Sometimes it feels that the more you know about "the system" as a whole, rather than your section, the less likely you are to be pigeon-holed into one role or another.

This can be both a positive and a negative - your career won't follow the normal "developer to senior developer to team lead" path, but you will end up being given tasks as a developer that would normally be assigned to someone with a much more senior job title would get.

The negative is that getting paid for your extra knowledge is extremely hard, and your extra knowledge it worth much less outside of your industry (or even outside your building), so moving jobs won't help so much.

Been there done that. Only thing I can suggest is that you keep notes, very good notes. You start looking into the WhatchaMaCallIt.java class to fix a bug you've been assigned? Write down in a text editor what you think it does in human understandable sentences. Then see how it interacts with other objects in the application. Draw squiggly lines with notes on them. You get briefed by a very experienced senior developer with absolutely no time? Keep notes of what he/she is saying and try to ask questions if something doesn't make sense. Also thank them for their time, always appreciated since I'm that guy now. I remember filling up notebook after notebook at my first job out of college. I then moved on to text editors that I could keep open in a second monitor (hidden whenever coworkers came by because I was embarrassed, which was stupid in hindsight).

From one of the featured comments:

>Yeah, if it were up to me, 10% of our time would be spent on training-- teaching, learning, research, etc. But the higher-ups will often veto that, because on paper, it looks like it takes them 10% longer to complete their projects. Never mind that well-trained people work better and faster-- that's difficult to measure.

Actually, the effects of training are very easy to measure, compared to most of the other stuff involved in management; the problem is that very few are willing to put in the time needed up-front before you can get anything to measure.

Thought i'd add my story, just started my first 'grown-up' programming job as well recently, three months ago.

I manage my company's internal management software, it allows the sales, support, development, testing, HR and contracts departments to operate as a 'paperless office'.

The first week, one of the first tasks I was given was to spend some time developing a simple plugin that displayed all the employees. From that, I had to research how the Entity Framework data models map to the object models within the software, how these models C/R/U/D and then how the 'snap-in' (the software uses a plugin based system, allowing different plugins to be updated specifically over updating the entire client) works with the host 'shell',

Although, I disagree with #1. If you're only doing the bare minimum, you're digging a hole in this massive system that'll come back to bite you. To make sure Contracts can send quotations to our customers, I had to learn how the quotation price will change if we're discounting a regular customer, and if we're doing that, do we keep the units of sale from the last quotation?

That's only one 'snap-in' of the system, replicate that over the other departments, and you understand how everything clicks, and you can write better software.

(Sorry for the long read, thought i'd post my tale!)

> But the bank… was different. No one could give an overview of the wholesale mortgage management system.

As a side note: The fact that few folks understood the global mortgage ecosystem lead directly to the housing bubble. For the bankers, it was not a bug but a feature.

"it's all about finding balance"

I was thinking that the whole time I was reading. You can only eat knowledge as fast as you can chew it. Digestion takes time too.