

Ask WTF: Learning The Business - astine
http://thedailywtf.com/Articles/Ask-WTF-Learning-The-Business.aspx

======
babarock
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.

------
EwanToo
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.

------
stuff4ben
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).

~~~
sunraa
Cannot emphasize the note taking process enough. I did this quite often early
on. Don't forget to review them either. After a point it starts to sink in.
I'm still a pen and paper person but would highly recommend either method

~~~
msellout
Why not commit your notes as comments in the file (or docs or wiki, etc.)?

~~~
sunraa
I'm slowly migrating to electronic form but sometimes habits are just plain
hard to break. :)

------
billswift
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.

------
csmattryder
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!)

------
jpdoctor
> 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.

------
ryangallen
"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.

