Ask WTF: Learning The Business

Remy Porter · 2012-09-13

With a gigantic system like that, there’s little a single person could do, but that's the whole point of the machine. The art of programming is taking a really large problem and breaking it down into a bunch of smaller problems. The big problem may be difficult, or even impossible to solve all at once, but the small problems can be easy. You've got a big problem- a system so complex you can't understand it, and nobody can help. So focus on smaller problems- understand one piece.

On a large team, you can only ever play a small role. Developers focus on small pieces of the puzzle, managers just try to keep the gears oiled and the team pointing in the right direction, and if everything fits together okay, you might get a decent product out of it.

As much as we joke about WTFs here, most WTFs arise from the same reality: the world is complex and modeling it in software is hard. Even the most simple business process quickly spirals out of control when you start looking at the exceptions and the edge cases.

2012-09-13

Try adding this layer: have your boss, team mates and stake-holders spread across the globe in different time zones with zero introduction to the business and even less of an intro to the code base, which I would wager floats around 1-2m loc.

Fighting tooth and nail to get help with the build process, extension points, etc., etc. Even questions like "where do I put my code" go unanswered. It's demoralizing at best, but if you stick with it, you will eventually get through it because everyone else on the team went through the same thing.

As advice, I would recommend this: don't ever settle for one word answers. Dig and persist. Be a pest and takes notes. This about it, how the hell else are you supposed to learn?

2012-09-13

I feel that if I were running the department, I'd accept the overhead and just make sure developers could understand the applications and business they're maintaining. Is this so much to ask?

That's because you're learning it and not teaching it :)

Documentation and training take up a lot of time, and time is budget. I recall that doing prep for roughly an hour-long class took close to a day. About 6 hours to prep, 1 hour to present, and if people didn't take good notes, they'd just forget what I told them in a few days. So, roughly 1 business day for me, during which time I could've written a chunk of code.

Was it worth it? I thought so. I actually enjoy training. But many people don't. And even MORE people (usually business people or managers) say "Is it really worth our time to do that?"

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.

Anyway, yeah, that's par for the course. If you want to learn, ask questions gradually. It'll take a long time, but you'll get there. I don't think I'd expect it to be taught nicely and concisely, the way it was done in college.

DaveE

2012-09-13

As someone who just went through the same thing, I feel your pain S.N. I'm an intern at a pretty big company, and, having never been in this sort of environment, I felt confused since after I spent a week watching new-hire videos about company spirit, values (heck, even a product presentation video that explained what to write in what part of the whiteboard when presenting to a client), all the intro I got from the dev team I'm working in was "we use maven, here's a repo link". And the aforementioned link pointed at a code base of over 10,000 source files, some of which several thousand lines long with only a javadoc saying @Author David/Jack, etc. at the top. Searching for something would often hang my IDE for several minutes at a time.

So my only advice is this - keep digging. You're new and no one expects you to show up the second day at work asking "What's next?" Focus on the corner of the codebase you need. Once you have an understanding how it works, starting expanding outwards. I like to take lots of notes (mostly on paper - still haven't found note taking software as flexible as paper :p) and slowly wade through the code, stepping through the code in the debugger, jumping back and forth between implementations and interfaces, etc. Eventually it'll start making sense and once you understand why one piece of code was written the way it was, you'll start to see the reasoning behind the rest of the code a lot faster.

2012-09-13

A few advices:

Take an assignment. Choose any. You don't have to understand what it means and how to do it. Maybe choose the one which is more well-defined (look at that assignment description has very concrete criteria of completion).

It's tremendously easier to learn complex system in the context of an assignment. You can approach people who weren't approachable before, because you have a reason (assignment) that you need to accomplish. It's also easier to structure new knowledge -- as a tiny vertical, that goes across potentially many components, but all around this particular assignment.

Unsure about what to do because you know too little? Take an assignment ASAP and try it. Every time you start working ask yourself "what is the next step" and if you don't find answer yourself, ask your peers and ask your boss.

There are usually many people willing to do some training for you (like a private session, explaining you the arhitectural design of the system), you just need to know how to ask for it. Make sure you don't look arrogant, like, hey, you all owe me training, but rather look friendly and technologically curious. Focus on project, technology, assignments, do not focus on people and relationship issues.

Good luck!

2012-09-13

As a newby, you aren't going to understand the business. Until you understand the business, you can't understand how a particular component fits in to the overall picture.

The important thing is that you don't need to understand the business to do your job. That should be taken care of by your project manager/team manager/mentor, who does understand the business and project (or does well enough), and can break it down into bite sized chunks for you to develop.

Whilst you are developing code, you should be absorbing how the system works, and understanding more about your business.

I can understand how someone could get frustrated in this position, but it is unreasonable to expect a long period of time being trained on the project or business - that is NOT YOUR JOB! You're a junior developer - your job is to develop the chunks of the project you've been told to develop, not to be the understudy to the technical architect.

If you were transitioning onto the team as a project manager, or a technical architect, than for damn sure, you should be trained on the project. But then, if you are coming in to those roles, you should almost certainly have the domain knowledge required to understand the specifications, or the skills to pick that up quickly without requiring special training.

If you don't like this environment, look for a job in a smaller shop. "Bob's Country HTML Shack" or similar.

2012-09-13

I have gone through this at my current and last jobs. The best advice is whatever you learn write it down so that you can pass it on. I have been on my job (system engineering with very little programming) less than a month now and encountered the same thing. I have started a document that links pages on the wiki, share point and information I have received in conversations. I presented this to the director and the principal engineers and received praise for showing initiative. This is something the company doesn’t have and while I am not experienced enough to know if documents are wrong; I have been able to create a single location where one can start learning the system.

Steve The Cynic · 2012-09-13

"Knowing the business" and "being a technical architect" are loosely related at best, in that we usually expect someone at the level of the technical architect to know the business, so that he can take its oddities into account in the architecture-level designs.

However, knowing the business - knowing what the domain terminology means, how people use the software, etc. - is important. No, you don't need to be able to be a wholesale mortgage trader to develop a system (or a small part of such a system) for such traders, but it helps you to make the system better if you do have at least some understanding of what they do and how they do it.

Example, also from the finance industry, but this time in the equity side of things. One particular client had spawned the Project From Hell, a sort of trading report that had mildly exotic and distinctly idiosyncratic requirements, including being fed into someone else's automatic analysis system.

OK, so a couple of other guys had beat their heads on it, and had, in effect, run away screaming. So they gave it to me to look at. By this time I had already gained a better-than-merely-basic understanding of what equity trading involves, but that only helps at the general level. So the client sent in half a dozen of their senior traders (the guys who were doing the trades that I was supposed to be chewing through), and I gave them a presentation.

I stood in front of them in a meeting room and scribbled on a whiteboard, telling them what I could see from the requirements, and what I thought that meant about what they did from day to day. I highlighted cases I thought were weird, and so on.

And then I threw it open to them to tell me what I'd left out, what I'd included that should have been left out, and anything else that differed between what I'd described and what they did.

I got good feedback, and detailed answers to some specific questions. They got to see that I cared about what I was building for them, and that I wanted it to be right for them.

But I could not have done it if I didn't have a better-than-merely-basic understanding of what equity trading is about. (No, I don't know enough about it to be an equity trader, but I can understand what they are talking about, and who those guys on the NYSE trading floor were in Wall Street.)

Domain knowledge will help you to change from a code monkey to a productive builder of software. It is the most valuable knowledge you can ever acquire, although knowing where to find the ingredients for a Gimlet comes close. (That's a 50/50 mix of gin and Rose's Lime Cordial in a chilled cocktail glass, as dictated by God and Chandler. The lime cordial isn't so easy to find in France.)

snoofle · 2012-09-13

Collective Wisdom:
Get someone who knows how to do it to show you. Take notes, as you watch, make him back up and repeat a step if you don't understand it

Collective Wisdom:
Take notes

Collective Wisdom:
Don't try to know it all; just learn your small corner of the universe

All excellent advice.

This may help along those lines.

I've been doing this 30 years, and the first thing I do when I start a new job/project is start a series of Outlook Notes (or some sort of cheat-sheet file(s) if you're not using Outlook), each to be a quick reference for one specific thing. For example: db url/login/passwords you will need. How to extract a project from source control and hook into the build system, how this or that feature logically works, or a high level call stack to use as reference.

When you ask someone how to do something and they give you a 2 second hand-waving explanation, just say: could you please explain that in more detail - and WRITE WHATEVER THEY SAY DOWN, put it in your cheat sheet, and correct as required.

Given the idiots we all encounter on a daily basis, if you have half a brain, you will catch on; it's just slow going at first.

OBTW: if your boss expects you to hit the ground running even though you have little experience, you probably need to go find another boss; don't wait for him to be stupid and fire you - leave on YOUR terms.

2012-09-14

There is one more question: What do you really want in a long term perspective? The answer to that will have a big difference on your professional career.

To make live a little easier for you NOW, you should at least learn a little bit about the business domain. I met a lot of software guys working many years in the same company that didn't know even the simplest business terms.

But at some point in time you will realise that you can either try to be good in business or to be good in coding. Both domains are so huge, that you will not be able to be very good in both of them. If you want to be very good, you will have to decide. Otherwise you will remain average in both.

The path to business might lead you to be a good business analyst or maybe a good architect. If you are strong in comunication and like to work with people this might be the way to go. If you are good at it you are visible in the company and might be solved as a problem solver. But you will lose the grip on "high end" software development.

The path to software will never give you the details of the business and you will have to live with never having a deep understanding the business. You might never be really visible to the rest of the company. But also it might be more easy for you to move to a completely different company. Technology is technology. And you have the chance to become very good at it.

It all depends on where you put your heart into!

Martin

Ask WTF: Learning The Business

Featured Comments