| « How to Extract Text from HTML (Experts Only) | Page Not Found » |
Most of the emails that arrive in The Daily WTF inbox are some kind of a submission. Or a hate mail. But every now and then, some one will request something a bit out of the ordinary: advice.
Hi Alex, I recently started my first "grown-up" job as a software developer. As exciting as it is to get paid for doing what I love, I can't help but wonder if I'm expecting waaaay too from a company. My main issue is that I know virtually nothing about the (very large) application I'm maintaining, or even the business domain. There is a business requirements wiki (and a whole team who can apparently answer questions about it), but it's filled with words and terms that are so domain-specific that it's basically impossible to get a proper understanding of things. It feels like I'm learning to fly using only blueprints to a Boeing 747. I was really expecting that someone would sit down with me and give me a nice demo of the ins and outs of the application and the business, but no one seems to be willing or able to do that. Messing around with a test version of the application doesn't help either since there's no product documentation accessible and the little help that's available is littered with domain intensive keywords. I feel that "it's complicated" and "this is a fast-paced environment" is no excuse to skip proper training and to not give due importance to knowledge transfer to new hires. 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? How exactly am I supposed to understand the application if no one else seems to know (or be willing to share) what it does? Sincerely, S.N.
I do my best to respond to inquiries like this, but this particular email had no return address. So that got me thinking… why not publically answer inquiries like this?
First and foremost, I'd like to welcome you to the machine, S.N. You are now officially a small cog in a small part in the impossibly complex machine that makes the world turn. As software developers, it's our job to model this very same machine, or at least our very small part in it, so that it can turn that much more efficiently.
My first appreciation for all of this came with a job at a bank. By then, I had already done the mortgage thing and I felt pretty confident that I'd be able to understand how the bank's wholesale mortgage management system. Waitasec. Wholesale mortgages? I thought banks worked by lending depositor's money at a higher interests rate than they paid out? Waitasec. Banks fund loans originated by brokers? And they sell these loans on an exchange? Uhh, I thought Fannie Mae made chocolates or something?
Up until this point, I could understand the applications I built and maintained. I prided myself on not only being able to write great code, but on understanding why the code needed to be written and the costs/benefits of that code. One time, I even saved the business thousands of dollars (and many lines of code) by insisting that we cancel building the search feature and instead train the handful of users to CTRL-F. I would have never come to that conclusion without taking the time to understand why the requirement existed.
But the bank… was different. No one could give an overview of the wholesale mortgage management system. Developers and business analysts kinda had an idea how some of the pieces worked, but no one seemed to truly understand how things fit together. And everyone was okay with that. They just did their job and focused on their corner of the world, whether that was an elegant architecture or a masterpiece requirements document. I found myself at a crossroads, in fact the very same one that you, S.N., are at today. Now it's time to choose a path.
I took the path less traveled and tried to learn both, but I quickly found out that the more I learned, the less the I understood.
Every corner I turned – whether it was on the loan origination side or on the loan packaging side – lead to an entire field of knowledge that I couldn't truly understand without years of experience. To write code that helps the "numbers guys" hedge risky mortgage risk, you don't really need to know what the broker registration system does. And thus, there was a good reason for no training or extensive documentation: it would fill an entire Library of Congress or two, or it would be uselessly terse and offer no real understanding.
The only way that the wholesale mortgage management system – software, process, people, and all – could work is if everyone masterfully played their own part. The business analysts needed to understand the requirements so that I could code to their specification within the larger system that the architects designed, all at the direction of project managers who are implementing the executive team's directives. It's exciting to be part of such a large system and solve all the complex development challenges surrounding it. But it still meant that I'd be "only" writing code, and the only way to build software was to do something else. So I did.
I started Inedo and went on to build software (BuildMaster and ProGet). But just as software is more than just code, a start-up is more than just software. I had to learn and do a whole lot more than I bargained for – accounting, marketing, legal – and as a result, I hardly write any code any more. It's exciting in a different way, but there are days I long for just writing code.
So to sum up my advice to you, S.N., it's all about finding balance.
If you want to work on the big, Boeing 747-sized projects, you'll have to accept that you'll never be able to fully understand everything you'll be working on. 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. But be careful, the closer you get to fully understanding the operation of the business… and you may just become it.
Have a pressing question that you need answered? Need advice? Send us an email: inbox@worsethanfailure.com The WTF "doctor" is always in.
|
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. |
Re: Ask WTF: Learning The Business
2012-09-13 09:36
•
by
A small cog in a massive multinational machine
(unregistered)
|
|
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? |
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 |
|
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. |
|
A few advices:
1. 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. 2. 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! |
Re: Ask WTF: Learning The Business
2012-09-13 11:04
•
by
Herr Otto Flick
(unregistered)
|
|
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. |
|
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.
|
|
"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.) |
Re: Ask WTF: Learning The Business
2012-09-13 12:14
•
by
snoofle
|
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. |
|
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 |
| « How to Extract Text from HTML (Experts Only) | Page Not Found » |
Collective Wisdom: