Ask WTF: Learning The Business

  • Overqualified 2012-09-13 09:08
    Get used to it.

    My current project 11M lines of code, 100 interacting threads, multiple levels of abstraction through jump tables, no documentation, no support, on my own. Oh, and did I say that it is used in military aircraft control systems!
  • Warren 2012-09-13 09:13
    You will gradually get a hold of it. I don't know how, but if you want to, I can only advise you look at everything you can inside & outside the company.

    And when you do understand an area, and everyone comes to you as the "expert", you won't feel any more comfortable than you do now....
  • Robyrt 2012-09-13 09:15
    Yeah, you'll never know the entire purpose, function and rationale of the system, but new hires should still get a one-hour crash course from the analysts on basic domain terms, like "originating" a mortgage, and the overall project plan, which you should have summarized for the original pitch already. From that point, figuring out what the code means becomes a lot easier.
  • snoofle 2012-09-13 09:16
    Ignorance is bliss - enjoy it while you can.

    Once you know the ins and outs, you become one of us...
  • Anoldhacker 2012-09-13 09:19
    I appreciate Alex's statements, but they don't address the actual question. Alex is talking about the breath-verse-depth issue when dealing with large systems. This question is about proper orientation.

    Yes, any operation which is even close to properly run will have an orientation designed to inform the new employee of the information that they need to be able to figure out how to do their job.

    No, there aren't very many operations which are even close to properly run.

    Sorry kid.
  • Remy Porter 2012-09-13 09:25
    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.
  • Dave 2012-09-13 09:31
    My only level of input here is "I understand"... I am currently a SQL and Datamining guy, and the one big application my efforts support, my team doesn't actually use or know very well.

    So when an end-user asks me to extract XYZ data, if it includes datapoints I am not already familiar with, there's often a whole several-day process in which I have to:

    - hunt down somebody who works on the application to find out what module, page, and field the end-user is looking for

    - then hunt down one of the guys who can tell me what tables in the transactional DB said page points to

    - then between myself and my boss, find or figure out how and where the transactional table ends up in the datawarehouse.

    So much of this could be resolved by a crosswalk document or two, but no such luck. Every time we make a new discovery I just add it to the knowledgebase of 'codebits.txt'.
  • A small cog in a massive multinational machine 2012-09-13 09:36
    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?
  • davee123 2012-09-13 09:38
    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
  • Nagesh 2012-09-13 09:38
    How you ain't getting return address from emails?
  • Remy Porter 2012-09-13 09:41
    It is possible, and honestly easy, to send emails anonymously. A fair number of our submissions come from people who use a non-existent email address as their reply-to.

    Yes, I know, I replied to Nagesh, but it's worth pointing out.
  • Nagesh 2012-09-13 09:42
    Thanking you, kind sir!
  • Martin 2012-09-13 09:56
    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.
  • lanmind 2012-09-13 10:05
    I've struggled with the same issues in the same business for years. In my case, it isn't so much that the problem domains are incomprehensible - what it usually boils down to is a combination of end users who never really understood the length and breadth of the domain themselves with an unhealthy dose of "this is just how it's done, because we've always done it this way", and a sprinkling of "that's just what the customer wants."

    For many years my department just coded to the end user specs, and what ended up getting produced was barely usable, with many rewrites, additions and subtractions. Frankencode from hell has been the norm. Part of the problem, which keeps me from (totally) blaming IT management, is the cultural idea that IT is a cost and a necessary evil, not a resource.

    But... I happen to be an owner, and I have a little bit - a very little bit - of leeway, and I'm not afraid to push issues when I see them. I'm not an expert code monkey; I consider myself only adequate. But what I do is the bane of Agilistas - the Big Deal Up Front.

    A big part of what my company does is agriculture, something about which I know very little. The existing system was a giant WTF, the domain was a great big unknown to me, and I needed to rewrite it. And we pump millions of dollars through it. What I did to make it happen was I took an entire year to work on and off with the primary users, actually helping them do their jobs. At times, I even filled in for them when it was needed. All the while, I did the absolute minimum to get by in the code - often by massaging the data directly - which in reality wasn't very much less than my predecessors. By the end of that year, though, not only did I know enough to rewrite the apps and reports, I was able to solve the problems that flew below the users radar.

    The take away is that I think I write much more useful software when I am not just a code monkey, but also a business professional. In some ways, my paradigm is diametrically opposed to the way the Agile folks do things. They've got some good ideas, but IMHO the Agile crowd are... well, that's another discussion. Still, I think the balance that Alex speaks of has a lot to do with how you will/are forced to work.
  • justsomedudette 2012-09-13 10:13
    I agree with the OP it's not OK but it is what it is. I've just started my third book of notes and I have loads of files explaining even the most basic details of code, procedures and the business in general. It has certainly helped me in my work understanding the bigger picture, and while it's not a requirement of my job it has meant I've been able to ask important questions when change occurs.

    As everyone has said, yes it's frustrating but little by little you'll get there, and when you do you'll be able to help those who follow you (you may not get a financial reward but it's good karma).
  • Ben Jammin 2012-09-13 10:16
    This kind of work environment also stresses the importance of good code. Being a small cog in a huge machine, other cogs get to look at your code and modify it when necessary. It may be months/years after you wrote it, but it will someday need to be changed. That will be the day, if you were inattentive or rushed or God forbid incompetent, that code will end up on this site.
  • Probably your boss 2012-09-13 10:23
    Let me answer this as someone who hired you, or at least someone very much like that. I am in your bosses position, the only difference is that I've had a bit to drink tonight and the anonymity of the internet lets me dispense a little wisdom safely.

    You're disposable, 9 out of 10 of my new junior hires are useless. Let's face it, only 2% of people are developers and as far as I can see they're randomly distributed among the population. Every cent I spend on you beyond your salary is a waste of money and that absolutely includes training.

    So why did I hire you? Ah, simple, because you might be part of that 2%. Far above you lie my A-team, my star developers. These are the guys "getting stuff done". What I'm hoping is that I might luck in and in this bunch of new junior hires find that 2/100 who will pay off.

    Sure I could nurse you all, offer training and "mentorship" but hell, do you have any idea how much that would cost? I might raise the sucess rate to 10/100 (at most) but would waste months of man hours from my A-Team to do it. No, this way is easy, churn and burn, can't figure out a 747, not A-team material, go apply for a PHP role.

    Harsh but true, I'm not a social worker, I don't care about you and if I could find out where you sat in the 2% rule then we wouldn't even be having this conversation (welcome to the A-team). Suck it up or move on, there are plenty of rewards for you at the top (did I mention the A-team make well north of 6 figures?) but until then you're going to have to fight for your living and that means learning as you go (for a long time to come too).
  • An European 2012-09-13 10:28
    Probably your boss:
    I'm not a social worker

    Yeah, but you are exactly what's wrong with this world. *sigh*
  • Bearded Wise One 2012-09-13 10:29
    I think this is a OpWTF. In the first few weeks you're not going to be a master of the entire system understanding how all the flywheels turn the rods, which turn the cogs, which interlink with the exanguination devices, which drip on the vampire hamsters in the wheels, which makes the system work.

    What I would expect is to get a high level view of the system and the major components in it. Obviously as the company invests more institutional knowledge into you you'll learn more about each subcomponent. I've been lucky enough (in my professional life) to have supervisors that sit down with me for about 3 hours in the first few days to explain some of how the system works.

    When a new guy comes in that I'm required to mentor, I budget about 2 weeks of my time for "trainee support". It pisses my boss off to no end, but after showing them how much time I actually spend during that trainee period and how much my project schedules slipped, they stopped complaining.
  • morfizm 2012-09-13 10:48
    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!
  • Herr Otto Flick 2012-09-13 11:04
    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.
  • QJo 2012-09-13 11:26
    A small cog in a massive multinational machine:
    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?


    "Be a pest and take notes." Sound advice.

    More than once I have been in an environment where the procedure for doing something basic is long and overcomplicated. The only way to get through this is to 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, then when finished write it all up on the company wiki. Use the notes you have generated to test whether they actually do all work, and if not, amend them. Then write an ant script to do everything you have documented.

    This is the only way forward. When doing this, there's always somewhere it goes wrong, and when you ask, it's "Oh yeah, we forgot to tell you that / didn't you know that / why has your machine not been set up so that ..." and on it goes.

    Three months later there will be a new addition to the team, and you will be expected to baby him through the process of setting up his environment, and you'll be able to say: "Huh. When I was new I didn't have any notes to work from, I had to write them myself." (*sniff*)
  • Garrison Fiord 2012-09-13 11:26
    Attention, TDWTF. You are officially being put on notice. Look for my email.
  • anonymous bystander 2012-09-13 11:27
    Probably your boss:

    You're disposable, 9 out of 10 of my new junior hires are useless.


    and that is in no way, shape or form related to receiving no basic assistance in getting starting...

    or the quality of your decision-making when you make a job offer.. ?



    Probably your boss:

    Sure I could nurse you all, offer training and "mentorship" but hell, do you have any idea how much that would cost?


    about one-tenth the amount being wasted by the present method ?


    Probably your boss:

    Harsh but true, I'm not a social worker, I don't care about you


    you are (mis-)attempting to emulate the ghost of Harold Geneen, and I claim $5 for recognising that...


    For anyone not familiar with that scenario:
    Harold Geneen built ITT into a ( controversial ) international conglomerate in the 1960s and 1970s, inspiring praise and condemnation in roughly equal amounts along the way...

    However, his legacy was mainly a generation of American managers who skimmed his book, or read a magazine article about him and somehow managed to misinterpret it into the belief that "the key to successfully running a business" == act macho and repeatedly shout at subordinates that you "don't care" about them...

    Said generation went on to apply this belief in the 1980s and 1990s, yet curiously their businesses were often not successful, with entire industries falling to Japanese competitiors...


    cf Cargo-Cult Management, AKA "wearing a black jumper and jeans because that other guy used to"...
  • JCGIII 2012-09-13 11:36
    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.
  • JAG 2012-09-13 11:44
    I recall my first days as a developer. Take some solice in recognizing that it's OK to feel overwhelmed. I certainly did. Even with some hands on experience, the task at hand seemed way bigger than I could possibly imagine. I didn't know where to start. After a while, you get more comfortable with all of the unknowns. Don't get me wrong, you will make some mistakes, and sometime not knowing is going to bite you, but you'll eventually figure out when it's ok to not know something. As a for instance, my focus is on data work. While i understand some of what goes into maintaining a high avalailabity environment, and I have come to appreciate this, instead of feeling like I need to know about all that goes into it.
  • Steve The Cynic 2012-09-13 11:51
    "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.)
  • Cbuttius 2012-09-13 11:59
    Ok: on wikis you can create a link by putting square brackets around the term.

    Edit the wiki page if you are able and put square brackets around each term that needs describing.

    Note that the link will probably not exist yet, but in time it will be populated.

  • snoofle 2012-09-13 12:14
    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.


  • R. Tables 2012-09-13 12:17
    Welcome my son, welcome to the machine.
    Where have you been? It's alright we know where you've been.
    You've been in the pipeline, filling in time,
    Provided with toys and Scouting for Boys.
    You bought a guitar to punish your ma,
    And you didn't like school, and you know you're nobody's fool,
    So welcome to the machine.
    Welcome my son, welcome to the machine.
    What did you dream? It's alright we told you what to dream.
    You dreamed of a big star, he played a mean guitar,
    He always ate in the steak bar. He loved to drive in his Jaguar.
    So welcome to the machine.
  • ACrow 2012-09-13 12:34
    When I started at my current job, I was handed a "Getting Started" instruction list that outlined rather nicely how to set up your machine to build the team's current project from source (and how to get the source from the repository). The level of detail was somewhere around "Get boost_vXX.zip from yyy.zzz.tt/boost, extract to local folder and make environment variable BOOST_DIR."

    That got me up and productive fast. But it was a document that was made and maintained at the lowest-level by my team's members. Someone had just grown tired of holding the newcomers' by the hand. I got lucky.

    If your team does not have such a list, make one! Saves everyone's time. And if no-one in your team remembers the whole procedure, just fill the blanks when the next new person comes aboard (and they have to be figured out anyway).

  • rfoxmich 2012-09-13 12:46
    ...and may the source be with you young padawan
  • Tessellated Cheese 2012-09-13 13:00
    Remember that part of the job description when you applied that said "Must be a self-starter"? Well, this is where that comes in, and a big part of how they'll judge you.

    I actually think it behooves young devs to start in some sort of Tech Support and/or QA role when first joining such a company. This affords them the opportunity to contribute while learning the ins and outs (and foibles) of the system.
  • Ol' Bob 2012-09-13 13:26
    <rant>
    Welcome to my world.

    Lissen, kid (and, S.N., as it seems you just started your first job out of college, trust me, I am fully qualified age-and-experience-wise to be your father and thus can call you 'kid' - got that?), you are now in the Real World. This is not school. This is not an internship. This is not some ivory tower where everything is clean and wonderful, all designs are immaculately pure, and there's always time to slope off for a beer if things start getting tough. This is not an environment where someone is going to pick up your shirt and wash your socks and wipe your puckered little derriere for you. You are now in an environment where, despite not knowing said derriere from a hole in the ground (quick lesson - the hole in the ground smells better - stick your nose up your bosses backside if you need to find out), you are expected to Perform. This means that you are going to be handed an ill-defined requirement scribbled on the back of a three-week-old cafeteria menu by the illiterate monkey who just happens to be your project lead, which directs you to make a series of business-critical changes to an unknown number of programs which neither you, I, the project lead, or Jesus Christ hisself has a complete understanding of. No matter - it's your job now, sweet cheeks, and good luck with THAT! 'Training'? Gee, I remember that - it stops right after you get handed the pretty paper and take off the funny flat-topped hat. You need to learn something? There's a whole effing internet out there, my lad, and Google is only a mouse-click away. 'Mentoring'? Say *what*? Oh, you mean 'brainwashing-and-indoctrination'! Sure, yeah, you can probably get a senior suit to pontificate at you - and good luck with THAT! You want everyone to speak in terms that *you* can understand? Not gonna happen. All businesses, organizations, groups, etc, have their own little language. It's called "jargon" - a specialized language that experienced practicioners use so they don't have to use so many words that they forget WTF they were trying to say in the first effing place! And you're right - you don't know it. You learn by A) being clueless, B) asking questions, and C) figuring it out from context. This is a little thing we call "learning". It's not really hard - babies do it all the time. In twenty-two years they go from not being able to do anything but eat, pee, poop, and scream to being self-centered little barstuds who believe the world should be fed to them on an effing platter. Your inability to function in an unstrutured environment is not of interest or concern. Root, hog, or die! As far as programs go - there's exactly ONE way to learn what that they do - dig in and READ THE CODE! Documentation is bullshit. User's don't have a clue. Co-workers lack time and inclination. And, ultimately, nobody can stuff knowledge into your head. So how're ya gonna learn it? READ THE CODE! READ THE CODE! (What're ya gonna do?) READ THE CODE! Oh, and if the above seems a bit harsh - yep, reality's like that. If'n you can't hack it perhaps you'll work hard to shine up them apples, and polish up that brass, and decide that, really, that stuff you smell when your nose is up some illiterate monkeys backside is actually *roses*, and maybe you'll just get *yourself* promoted to illiterate monkey! I hear there's quite the supply of three-week-old cafeteria menus just waiting for hard chargers such as yourself.
    </rant>

    (Golly, I seem to be feeling a mite testy today. Heh. Probably just a reaction to the illiterate monkey's code I was reading...)

    CAPTCHA: similis - like a veneral disease, but not quite...
  • Orv 2012-09-13 13:30
    I'd add that every job I've started, I felt lost at first, and worried everyone around me would notice what a clueless boob I was.

    I've since learned this is entirely normal.

    You'll also find you really don't need to understand everything to be useful. I work as a sysadmin in a graduate department at a university. I'm surrounded by people MUCH smarter than me, doing research I can't even understand the abstracts of. But that's okay; after at most a few rounds of questions, I can usually get a handle on what they need from me in terms I can understand. My job is to deal with all the fiddly little details of installing software and running the systems, so they can focus on the big picture. Understanding the big picture, as interesting as it might be, would actually be a distraction from my work.

    To borrow the airplane analogy, the guys driving rivets or assembling engines at Boeing don't learn how to fly a 747 as part of their training. It'd be a waste of everyone's time, because what they really need to understand is the little piece they're working on.
  • Bob H 2012-09-13 13:36
    There is a story of a woman who worked in a factory assembly line for several decades, after a while she broke a record for never taking a sick day and being the longest standing employee. At lunchtime they held a celebration for her and in the course of which management asked her what she thought of the company product, she said "I don't own one and I don't need a new vacuum cleaner.". Guess what, they didn't make vacuum cleaners, not even close, but that didn't matter, she did her job effectively and worked hard.

    That said I am not sure I could work like that!
  • Ol' Bob 2012-09-13 13:42
    R. Tables:
    Welcome my son, welcome to the machine.
    Where have you been? It's alright we know where you've been.
    You've been in the pipeline, filling in time,
    Provided with toys and Scouting for Boys.
    You bought a guitar to punish your ma,
    And you didn't like school, and you know you're nobody's fool,
    So welcome to the machine.
    Welcome my son, welcome to the machine.
    What did you dream? It's alright we told you what to dream.
    You dreamed of a big star, he played a mean guitar,
    He always ate in the steak bar. He loved to drive in his Jaguar.
    So welcome to the machine.


    So...so you think you can tell heaven from hell?
    Blue skies from pain?
    Can you tell a green field
    From a cold steel rail?
    A smile from a veil?
    Do you think you can tell..?
    Or did they get you to trade your heroes for ghosts?
    Hot ashes for trees?
    Hot air for a cool breeze?
    Cold comfort for change?
    Did you exchange a walk-on part in the war
    For a lead role in a cage?

    How I wish...how I wish you were here
    We're just two lost souls swimmin' in a fish-bowl
    Year after year
    Runnin' over the same old ground
    What have we found?
    Same old fears
    I wish you were here.

    ...

    Nobody knows where you are, how near or how far
    Shine on, you crazy diamond
    Pile on many more layers, and I'll be joining you there
    Shine on, you crazy diamond!
    And we'll bask in the shallows of yesterdays triumphs
    Sail on the steel breeze
    Come on, you boy-child, you winner and loser
    Come on, you miner for truth and delusion, and shine!

    CAPTCHA: feugiat - (Sticking with the Floyd motif):
    Feugiat, we gotta get on with these
    Gotta compete with the wily Japanese
    There's too many home fires burning and not enough trees
    So feugiat, we gotta get on with these
  • jay 2012-09-13 13:45
    Part of the answer is that this is the difference between big systems and small systems.

    On a small system, it's perfectly reasonable for every team member to understand what the entire project is about. Not to have every field on every screen and every line of code memorized, of course. But competent team members should know that we have some screen where customers enter orders and they have to select the items they want and enter their shipping and billing information, and we have a database with a table for all the products we sell and another table for all the orders, etc etc.

    At some point a system gets big enough that this is impossible. If you are working on the vacation and sick time modules, you may be dimly aware that there is a company-paid disability insurance module, but beyond its existence you know nothing about it. There may be whole subsystems that you don't even know exist.

    Personally, I hate working on such big systems. Part of it is purely emotional: I don't like being a tiny cog in a big machine, where I don't even know where we're going or why. But on a practical level, such big systems have problems that small systems don't. The things you are working on have subtle interactions with components that you know nothing about.

    Every change you make has the possibility of breaking parts of the system that you didn't even know existed. I've run into this many times: I modify inventory management, and inadvertantly create a bug in shipping manifests. I modify customer name and address entry and break promotion discount calculations. Etc.

    Different groups may find themselves working at cross purposes. The order processing group is designing a new search function based on inventory category while the shipping group is working to eliminate inventory category from the database. As no one knows the big picture, no one knows how all the pieces really fit together.

    There are ways of dealing with such issues, of course, but no one has yet found a true SOLUTION that makes the problems go away.

    I once saw a study that compared the size of a system to the success rate. It was no surprise to me that the success rate for very large systems was extremely low. I used to work for the Air Force, and it seemed like every couple of years somebody got the bright idea that we should have one giant system that tied together everything that the Air Force did. Instead of having one system to manage inventory and another to order parts and another to handle payroll and another to plot flight paths, etc etc, why not have one system that tied it all together? So like the general could type in that he wanted to send a squadron to bomb this particular target, and the system could automatically requisition the bombs from inventory and calculate fuel requirements and give the pilots their combat hazard bonus and notify the mechanics when the planes were expected to return so they could plan maintenance etc etc. Sounds like a great idea. And every time it was tried, they would spend millions or tens of millions of dollars on it, and never deliver anything. I saw probably half a dozen of these projects fail, one after the other. Because human beings are simply not capable of managing something on that scale, at least given the current state of the art.
  • jay 2012-09-13 14:04
    Something I've always found fascinating about the IT business is that everyone expects the computer guy to come in and in a few months -- or a few hours -- know more about how the business works than the people who have been doing it for decades. I once got a job with a company that made software for doctors' offices. And bam!, I was immediately expected to know all about "International Classification of Diagnosis" codes, how doctors' offices interact with insurance companies, how medical records are kept and organized, etc etc.

    In some ways the IT guy has to know the business better than the business people. The business people often deal only with the routine cases, but the IT folks have to consider every possibility. I don't know how many times I've had conversations where I bring up some abnormal case, like, Me: "What should the computer do if there is only enough stock to partially fill the order? Do we send the customer what we have and back order the rest, or do we send nothing until the whole order can be filled, or what?" Business person: "Oh, don't worry about that case, that hardly ever happens." Me: "But it must happen sometimes, right?" Business: "Well yes, sometimes, but not often." Me: "So what should we do when it happens?" Business: "Oh, don't worry about it, it's very rare." Me: "But the computer has to do something in that case. I can't tell the computer to just not worry about it." Business: "Will you stop wasting time on these rare cases! I told you it hardly ever happens! Just do something reasonable!" Me: "Okay, so what's 'reasonable'? Should we make a partial shipment?" Business: "Not necessarily. It depends." Me: "Okay. Depends on what? Under what conditions do we make a partial shipment?" Business: "I don't know, it just depends. Stop bothering me with these details! Just do something reasonable!" Etc. I've literally had users get yelling mad at me for asking them about details and special cases.

    But the IT guy has to consider every possibility and every detail. While the operating folks can make things up as they go along, use their judgement, etc, the computer can't. We have to distill everything down to hard and fast rules. Which means we have to know all the details.
  • mainframe web dev 2012-09-13 14:08
    >> How exactly am I supposed to understand the application if no one else seems to know (or be willing to share) what it does?

    What a great opportunity!

    Read the source. Find the program entry point, and the modules that execute at startup. Find the secondary storage, file and database routines. Find the user input areas.

    Take a each module/class and try to understand what it does.

    Once you know how to navigate the source, you will understand the how, if not the why.

    And the real secret -- grab your nearest company old-timer and take him out for beers.
  • ben 2012-09-13 14:11
    Look, if you want to write some spiel about what you think the young folk should do in their first jobs then write it. I don't see the point, myself, but whatever. But don't write a fake letter that subtly acknowledges how great you are with the lie that "this particular email had no return address", OK? Who do you expect to believe that? Who are you, Cary Tennis? Fakery and bullshit and lies are never appealing. Just speak your mind if that's what you want to do.
  • Kuba 2012-09-13 14:20
    The advice to just "suck it up" is precisely what's wrong with the business software non-engineering. I'm not arguing that anyone can get the entirety of a large system in their head, that's not usually possible. But I do argue that a certain process must be followed that not only yields higher quality software, but also improves the situational awareness of team members.

    Some advice from IEC 61508 and UL 1998 as to the management of the software engineering process wouldn't hurt. I can't understand people who, in a large business setting, argue for and code without having traceability from requirements at least to code, if not to tests and validation. That process is exactly what's called for when you have a big team, as everyone can refer to the managed documentation and understand the cog that they work on, or even have understanding of the structure of the whole system, should they need to.

    It's not about training, it's about having a process that adds value to the company. Suppose the big bank irks their IT team and everyone walks off the job and resigns, upset so much that no money on the planet will get them to consult for the bank. The replacements will spend months just figuring out where the latest version of the code is, much less what the heck does it do. You'd think that the notion of replaceable cogs in the machine would appeal to the beancounters, but apparently they pay lip service to it only.
  • Kuba 2012-09-13 14:22
    mainframe web dev:
    >> How exactly am I supposed to understand the application if no one else seems to know (or be willing to share) what it does?

    What a great opportunity!

    Read the source. Find the program entry point, and the modules that execute at startup. Find the secondary storage, file and database routines. Find the user input areas.

    Take a each module/class and try to understand what it does.

    Once you know how to navigate the source, you will understand the how, if not the why.

    And the real secret -- grab your nearest company old-timer and take him out for beers.
    Program entry point? Typical enterprisey clusterfuck may have a hundred executables, working on dozens of servers, and understanding of what every individual executable does gives you absolutely no idea what the whole thing is doing -- not until you read through a megabyte of XML configuration files, and figure all the string and chewing gum that's holding it all together. IOW: you must have never seen a "serious" enterprise deployment.
  • Hmmmm 2012-09-13 14:27
    ben:
    Look, if you want to write some spiel about what you think the young folk should do in their first jobs then write it. I don't see the point, myself, but whatever. But don't write a fake letter that subtly acknowledges how great you are with the lie that "this particular email had no return address", OK? Who do you expect to believe that? Who are you, Cary Tennis? Fakery and bullshit and lies are never appealing. Just speak your mind if that's what you want to do.

    Anyone else been having a crappy day and feels like they need a rant?
  • Kuba 2012-09-13 14:28
    jay:
    Every change you make has the possibility of breaking parts of the system that you didn't even know existed. I've run into this many times: I modify inventory management, and inadvertantly create a bug in shipping manifests. I modify customer name and address entry and break promotion discount calculations. Etc.

    Different groups may find themselves working at cross purposes. The order processing group is designing a new search function based on inventory category while the shipping group is working to eliminate inventory category from the database. As no one knows the big picture, no one knows how all the pieces really fit together.

    There are ways of dealing with such issues, of course, but no one has yet found a true SOLUTION that makes the problems go away.
    I couldn't but chuckle at your suggestion that "no one has yet found a true SOLUTION". The solution is called a software engineering process. You know, stuff when you have requirements that are traceable to design, traceable to code, traceable to tests and validation, and to the results of those. All this so that when you have a piece of code, you can look up exactly what requirements does it implement, how and why was it designed in a certain way, where the tests for it are, how is it deployed, and everything else.

    IOW, it's a solved problem, there are even competing software tools to aid you in this process! Heck, there are even tools that aid in risk estimation, and help you decide to what level of testing and validation a particular software module should be tested. It's not popular outside of safety-critical system circles, but if there were no solution then we'd have modern fly-by-wire planes falling out from the sky left right and center, and various process industry plants would be blowing up every other week. Get real -- just because you have no clue about something, doesn't mean it isn't a solved problem.
  • Remy Porter 2012-09-13 14:28
    My employer has a centralized database for tracking health and safety information for dangerous chemicals. Now, the data doesn't start centralized- it needs to be gathered and scraped from a thousand legacy applications that were used by a variety of business units. And then, once it's managed in the central system, changes have to migrate back out to those legacy systems, where people actually do their work.

    Now, the underlying design of this is full of WTFs driven by doing integration in the data-layer, and it could certainly have been done better. But due to enterprise constraints, the actual implementation ends up being held together by hundreds of SSIS packages, scheduled console applications, mainframe FTP operations.

    When it comes time to answer, "How does Europe know if this chemical causes cancer?" the actual implementation of the process is spread across so many different systems that no one person can answer the question.

    The amazing part is that the process works. It's business critical, it's arcane and complex, but it works fairly consistently. You don't realize that it's terrible until something goes wrong, and then you learn that there's really no way to understand what went wrong.
  • Kuba 2012-09-13 14:31
    jay:
    I once saw a study that compared the size of a system to the success rate. It was no surprise to me that the success rate for very large systems was extremely low. I used to work for the Air Force, and it seemed like every couple of years somebody got the bright idea that we should have one giant system that tied together everything that the Air Force did. Instead of having one system to manage inventory and another to order parts and another to handle payroll and another to plot flight paths, etc etc, why not have one system that tied it all together? So like the general could type in that he wanted to send a squadron to bomb this particular target, and the system could automatically requisition the bombs from inventory and calculate fuel requirements and give the pilots their combat hazard bonus and notify the mechanics when the planes were expected to return so they could plan maintenance etc etc. Sounds like a great idea. And every time it was tried, they would spend millions or tens of millions of dollars on it, and never deliver anything. I saw probably half a dozen of these projects fail, one after the other. Because human beings are simply not capable of managing something on that scale, at least given the current state of the art.
    The scale of such a project is quite comparable to the scale of system engineering done on a modern fly-by-wire jet or a large process industry plant. IOW: people who have a clue know exactly how it needs to be done. Enterprise software weenies who wouldn't know engineering if it hit them on their heads, on the other hand, ... well, there you go.
  • savar 2012-09-13 14:59
    Alex, this is the best article you've ever posted on TheDailyWTF. I could see this becoming a regular feature.

    Also, it's funny you mention Fannie Mae; that was my first job out of college. I have an Econ degree and CS minor, and I was still completely blown away by the depth and complexity of their business. Fortunately, Fannie Mae offers (or used to?) an FNMA101 class to all employees and contractors that does a great job of explaining how the business works a high level. But in my experience, only really large organizations have the ability to pull of sophisticated training like that.

    Even with extensive training, the detailed business logic is still impossible to master because the business logic is driven by the real-world necessity of business people cutting idiosyncratic deals in any way possible to get new business. We had business rules at FNMA like, "if the security code begins with "M" and it was originated in Arkansas or Arizona between 1996 and 1998 with a mortgage amortization code of 17, then put it into file A, otherwise put it into file B". The reason behind that business logic is some guy (who probably didn't even work there by the time I started in 2006) put together a 3 year deal with banks in Arizona and Arkansas to process loans in a particular way for them.
  • savar 2012-09-13 15:22
    Probably your boss:

    Let's face it, only 2% of people are developers and as far as I can see they're randomly distributed among the population. Every cent I spend on you beyond your salary is a waste of money and that absolutely includes training.


    I think you mean, "only 2% of people WHO CLAIM TO BE DEVELOPERS are developers," right?

    If 2% of the population were developers, then it would be much easier to hire the right talent. I've struggled for years at small companies to hire qualified developers. Half of the guys that come in can't even write FizzBuzz on the first try. (Admittedly, in many of my cases, the small companies just couldn't/wouldn't pay enough to hire the right people.)

    In either case, if you're hiring entry-level employees and then consider their training to be a wasteful overhead, then you're an asshole. Entry-level software developers will undoubtedly require more training and hand-holding to get started than an experienced developer. There are a lot of tools and skills you just don't typically learn in school, and there are also a lot of life lessons about how to interact with coworkers that aren't taught in schools either.

    If you don't have time to train an entry-level employee, then don't hire them. You're not doing them or you any favors by setting them up for failure.


    Harsh but true, I'm not a social worker, I don't care about you and if I could find out where you sat in the 2% rule then we wouldn't even be having this conversation (welcome to the A-team).


    I'm not suggesting you should run a welfare agency. By all means, hire effective people and fire ineffective people. But don't treat people like shit. Even if I was on your A team, I wouldn't want to work for somebody like you.
  • PedanticCurmudgeon 2012-09-13 15:38
    savar:
    I'm not suggesting you should run a welfare agency. By all means, hire effective people and fire ineffective people. But don't treat people like shit. Even if I was on your A team, I wouldn't want to work for somebody like you.
    What, you don't like working for trolls?
  • Harrow 2012-09-13 15:40
    An European:
    Probably your boss:
    I'm not a social worker

    Yeah, but you are exactly what's wrong with this world. *sigh*
    I disagree. PYB may or may not be part of the problem; he doesn't exactly say what he does when one of the 1/50 shows up.

    Is perseverance frustrated? Is the A team allowed to crush anyone who might threaten their aura of superiority? Is any existing documentation (even other developers' notes) jealously hoarded in secret? Is a new worker ridiculed or even penalized for asking questions? If so, then PYB is even as you say.

    Or is perseverance rewarded? Has the A team been told to be on the alert for the rare gem? Are resources provided for the ambitious hungry talented? Is it possible (if difficult) to grow and progress? If so, then PYB is correct and is doing the best for his company overall.

    There's a big difference between "frustrating, hindering, and exploiting" and "declining to offer to help".

    -Harrow.
  • alpha doggg 2012-09-13 15:59
    You know ive been at that crossroads before and you know what I did? said "fuk dis" and got into accounting. Now I'm pulling six figures a year and I've got more $$$wag than you can shake a stick at. do yourself a favor and blow off this chump change programming crap your going for and become an accountant too. if you dont want to do that you can do the next best thing and off urself, skrub. get rekt

    alpha doggg

    hoooouwwwwwwwwwwwwwwwwwwwwwwwwwwwwww~

    (Captcha: Esse. Don't mess with me esse >;( )
  • no laughing matter 2012-09-13 16:06
    Ol' Bob:
    R. Tables:
    ...

    ...

    Ol'Bob is answering R.Tables and no link to xkcd in sight?
  • Matt Westwood 2012-09-13 17:13
    R. Tables:
    Welcome my son, welcome to the machine.
    Where have you been? It's alright we know where you've been.
    You've been in the pipeline, filling in time,
    Provided with toys and Scouting for Boys.
    You bought a guitar to punish your ma,
    And you didn't like school, and you know you're nobody's fool,
    So welcome to the machine.
    Welcome my son, welcome to the machine.
    What did you dream? It's alright we told you what to dream.
    You dreamed of a big star, he played a mean guitar,
    He always ate in the steak bar. He loved to drive in his Jaguar.
    So welcome to the machine.


    Odd coincidence: I was listening to this about the same time you were entering it.
  • Matt Westwood 2012-09-13 17:19
    Ol' Bob:
    R. Tables:
    Welcome my son, welcome to the machine.
    Where have you been? It's alright we know where you've been.
    You've been in the pipeline, filling in time,
    Provided with toys and Scouting for Boys.
    You bought a guitar to punish your ma,
    And you didn't like school, and you know you're nobody's fool,
    So welcome to the machine.
    Welcome my son, welcome to the machine.
    What did you dream? It's alright we told you what to dream.
    You dreamed of a big star, he played a mean guitar,
    He always ate in the steak bar. He loved to drive in his Jaguar.
    So welcome to the machine.


    So...so you think you can tell heaven from hell?
    Blue skies from pain?
    Can you tell a green field
    From a cold steel rail?
    A smile from a veil?
    Do you think you can tell..?
    Or did they get you to trade your heroes for ghosts?
    Hot ashes for trees?
    Hot air for a cool breeze?
    Cold comfort for change?
    Did you exchange a walk-on part in the war
    For a lead role in a cage?

    How I wish...how I wish you were here
    We're just two lost souls swimmin' in a fish-bowl
    Year after year
    Runnin' over the same old ground
    What have we found?
    Same old fears
    I wish you were here.

    ...

    Nobody knows where you are, how near or how far
    Shine on, you crazy diamond
    Pile on many more layers, and I'll be joining you there
    Shine on, you crazy diamond!
    And we'll bask in the shallows of yesterdays triumphs
    Sail on the steel breeze
    Come on, you boy-child, you winner and loser
    Come on, you miner for truth and delusion, and shine!

    CAPTCHA: feugiat - (Sticking with the Floyd motif):
    Feugiat, we gotta get on with these
    Gotta compete with the wily Japanese
    There's too many home fires burning and not enough trees
    So feugiat, we gotta get on with these


    ... and this too (the upper of the two) ... just so happens I was playing through all the songs on my mp3 player in alphabetical order and today I got up as far as W ...
  • MrDaniil 2012-09-13 17:40
    I find it to be a little funny that the Library of Congress is always a benchmark to the amount of written volume. Similar to horse power in modern cars/ships/jets/space rockets. I've never even been to Library of Congress. Is that place real or only in a dumb Cage movie?
  • x bored employee 2012-09-13 18:25
    The truth is most of the arrogant pricks in IT know a lot less about what their users want than they make out. They big up 'complicated' stuff because they don't understand simple business rules and so write code where you can rip 95% out if they bothered to try to put themselves in an accountants, or sales, or client service employees shoes. This new wave of agile isn't helping either as it appears to drive the bottom performers to actually do something for a change but hampers talent because they aren't allowed to stray too far from a story, it makes developers who do not understand the domain implement requirements like brain dead robots, and because most are arrogant pricks they will not listen to advice. I love programming business solutions but dislike most of the dick heads in IT so work freelance now so I can spent my productivity with people who actually think about what people want/need (rather than what they asked for in their requirements doc) and have much more interesting and less bullsht filled days. For now my advice is find a job with the smallest team you can find so you don't get patronised for your first five years, and develop a relationship with your users and ask them about their job away from your system - you will be sure to find new avenues for software development but above all you are much less likely to end up as a self satisfied prick talking about Cobol.
  • Silverhill 2012-09-13 22:30
    MrDaniil:
    I've never even been to Library of Congress. Is that place real or only in a dumb Cage movie?
    The world's largest library is indeed real. Read a buncha stuff about it here, for instance: http://en.wikipedia.org/wiki/Library_of_Congress
  • Cheong 2012-09-13 23:34
    I don't know... When I first joined a software house developing equitiy trading application, I know nothing about stock market.

    Then I spend 3 months of my spare time to learn how to be a broker, and I started to go work. (Although I'll also lucky enough to have peers working on the same project, so in cases that I was not so sure, I can ask.)

    If you ever need to work with a very domain-specific system, you should learn as if you need to become one of the users.

    Specifications from PM and seniors won't always work because they usually won't go into too detailed part. You have to understand what you write to avoid making stupid mistakes.
  • Spookman 2012-09-14 01:06
    As a team lead, I am often tempted to throw a new employee in at the deep end just like this... as a test.

    As many other posters have said, these kinds of systems are huge, and the domain is full with jargon. Explaining the whole system would take three years of time from my best developer.

    So, the test is to see if you're the kind of person who can pick one small problem, and figure out enough of that tiny corner of the application for yourself. What is your level of independent, self-training go-get-it-ness?
  • Martin 2012-09-14 02:32
    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

  • Americhanac 2012-09-14 03:21
    Excellent article, sound advice. Well done! Hard to find a common-sense read in SEO optimized sites these days...
  • justanothercodemonkey 2012-09-14 04:59
    To me, the problem described in the OP is one of the biggest WTFs in the business.

    I get that I may not understand everything, but how many times have you thought a requirement looked a bit spurious and queried it, only to get to a business analyst, or someone in the business whose only answer is 'I dont know' or 'Its always been that way'.

    I find that point incredibly frustrating as its just their laziness creating more work for people down the line. I can think of loads of occasions where I've chased requirements further only to find that its some unused piece of legacy functionality. You'll typically only find this out by finding an end user too - noone higher up wants to admit they dont have a clue what that mystery button does.
  • ceiswyn 2012-09-14 06:57
    Have you tried asking the doc team, training team or customer service team if they have any overview documents or training materials that can give you some context?

    A good doc team should know the application inside-out at a conceptual level (surprisingly few companies seem to have good doc team, but that's a separate issue).

    A lot of software departments just throw new hires in at the deep end, but that doesn't mean the information isn't out there; as long as you're not fixated on your own team and command chain being your entire world.
  • despair tyre 2012-09-14 07:31
    Probably your boss:
    ... the anonymity of the internet lets me dispense a little wisdom safely.


    By claiming wisdom you make it very clear you don't have much.
  • urza9814 2012-09-14 10:00
    I'm consulting for a pharmacy near the top of the Fortune 500 and I'm having the opposite problem. Getting close to two months here (plus six weeks training before the client site) and I haven't _really_ written a single line of code yet. One or two test scripts, but that's all. Been just learning about the system the entire time.

    Of course, part of that is due to the fact that, on a good day, I'll be able to get a one hour session in with someone and maybe read some documentation...I exhausted the independent training plan long ago though, and spent a while trying to find other documentation and looking at scripts and such, but at this point a large part of my day is spent reading Slashdot and TDWTF...
  • Alex 2012-09-14 10:17
    You need a big flow diagram fairly high level, a pointer in each box to the documentation store and experts on each area.

    Look at the flowchart, pick a box, read the documentation, talk to the experts. Aim to get your name in a few boxes!

    Or you can just say its far too complex and develop mediocre code or provide bad support.

    I have seen both types of organisation, the second one is more common and painful.
  • radarbob 2012-09-14 11:43

    the significant problems we have cannot be solved at the same level of thinking with which we created them. - Albert Einstein


    * Expect to learn un-systematically.

    * Make a personal copy of the code (or version control branch) for your own playground.

    * Comment the hell out of the code - WHY, not what. Constantly modify same as your understanding increases.

    * Break code on purpose to see how behavior changes.

    * Make UML-correct class diagrams, sequence diagrams; Database entity diagrams, etc. Use these as props for questioning your co-workers.

    * Keep code criticism objective and professional. NEVER say "Who wrote this code!?"... out loud. Never.

    * Learn the details of how they did the "grunt work" that all apps have - populating screens, business objects, database fetching; "layer interfacing" I guess you could say. Look for patterns - of the personal coding kind vis-a-vis formal design patterns. Soon this "white noise" will fade, and the business-relevant stuff will be easier to see and learn.

    * Schedule lots of time to sit with your customers using the system. Be sensitive of their workload & time constraints; don't be asking lot of questions when they really need to get work done.

  • radarbob 2012-09-14 12:01
    An European:
    Probably your boss:
    I'm not a social worker

    Yeah, but you are exactly what's wrong with this world. *sigh*


    WTF? Is being on the pointy end of a downsizing, for example, any better because the boss is a nice guy? Do you think they started the business just so they could hire you? Only 1 person can get promoted, folks get fired sometimes no matter how much the boss doesn't want to. Very hard decisions have to be made all the time. I sure don't want it to be easy for them because I'm a slacker.
  • Anonymous 2012-09-14 12:07
    This doesn't just happen at large companies where there are business analysts, etc. all doing their part. Sometimes there is just one or two other developers/IT staff that know everything. When they are out on vacation or sick and you're expected to hold everything together, good luck. The best skill I've learned is to take everything in stride and try to keep emotion in check. No matter how invested your are, it is just a job, although perhaps lives and more are on the line, but you just do what you can. Try not to think about it too much when you leave work for the day.
  • wbrianwhite 2012-09-14 15:04
    This is the kind of thing we're looking at fixing in our company right now.

    Taking the minimal approach, our team spent a couple weeks writing up "how our system works", "what new hires need to know", "how to keep your system running" etc. in One Note. Shared One Notes are a nice alternative to wikis as there is no learning curve at all, you can embed images, files, etc.

    Actually setting up our system... we gave up on that years ago. Thank god for VMWare player. We just keep a VM updated (sorta) so that new hires start with a working system.
  • Jeremy 2012-09-14 15:12
    From my experience, as a software developer, you're expected to be an "expert" (after all, you automate their business). Managers recognize your time is valuable and don't want to waste it training you in something you may already understand (or understand well enough that the details don't really matter). However the programming staff should be willing to show you the ropes and walk you through some things.

    If you like the company, people, projects, etc. well enough to stay, then my advice would be to give it time. 12 years ago I started working on a project and a team environment that sound similar to yours. I started out just writing code (2 maybe 3 years), then I got tired of not understanding the benefit of what I was doing. For my own satisfaction I needed to know that what I did matters. Since I knew most of the technical ins and outs by then I made a point of asking questions about "the business" and how the requirements satisified their business problems. If nobody has ever asked those types of questions before expect some push back (but I imagine that most of the stuff we see here is from programmers that "just code") as it's a cultural change that you're driving toward. Eventually people will get why you ask those types of questions when you start identifying easier, cheaper ways of doing things without spending thousands of dollars on a customized software solution. You will be a hero to the company, a well respected software engineer and you will learn the business, but it takes time.

    For me it took 3-4 years to learn most of the aspects of the business that my software directly effects and I say most because business constantly changes. I've got the big picture and a lot detail in how processes work, but I have learned that I have to be adaptable to the ever changing "business"... There will always be more to learn.
  • hallo.amt 2012-09-14 21:05
    Hi, I happened to start a new job a few month ago. I work for a company that sells electricity and owns a few small grids. On my first day working there the migration of all the customers to a new system was nearly completed one just had to press a few buttons. I did not know anything about the business yet. But I took the small task to
    export the contacts to a format readable to the new system. I was able to use any tools I needed which was a big advantage and somehow learned to know the old system a bit. The more tasks like that and now I know a bit about the processes in that business.
    Just show you're interested in the big system and learn it in small steps. You might eventually get the big picture but it does not matter if you get it as long as you can do some useful thing in the system.
  • Sean 2012-09-15 00:27
    Wow, this needs to be recorded in annuls of developer lore. Every time you think you got it whipped something else jumps out and the project blossoms new requirements.
  • Sean 2012-09-15 00:33
    As a young man that was my main talent, shedding the workday. Trying to get it back....important.
  • Anonymous 2012-09-15 21:22
    I second the suggestions to take notes; but don't use a text file or other flat format. Use OneNote or a wiki (it's fairly easy to set up a local/personal MoinMoin wiki, for example). (I would not recommend using a remotely hosted note-taking service such as EverNote because you'll likely want to take notes about source and other information considered corporate confidential and they'd probably not be appreciative of it being stored on servers outside the company, no matter how secure they may be.) Personally I really like OneNote for it's instant search capabilities (if I could find an open source equivalent I'd use it), and it's standard with Office 2010. Ideally you can share the wiki/OneNote with other developers, depending on local policies; even if not, even a local one will be useful for you.

    If you end up creating tools useful for you but that management doesn't want added to any official repository, create your own local repository with git etc. (and if you can, back it up to a share that is backed up by IT, since it's still work product). I have a number of Python tools I've created and use regularly that increase my efficiency. If you find yourself repeating something, you can probably automate it - and should, if you'd save time by it.

    I would also recommend the short O'Reilly book Code Simplicity; it defines a lot of important and valuable principles. Source code in the real world, of course, laughs in the face of principles of software architecture, but perhaps you can at least not add to the crap.
  • Syntax 2012-09-16 03:52
    morfizm:
    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).
    -- SNIP --
    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!

    Amen!! Perfectly put
  • Syntax 2012-09-16 04:26
    Reading through all the comments is fascinating and depressing at the same time.

    I've worked in several dev roles and for the last 4 years as head of development/infrastructure. It's a smallish team but the codebase is mature. Everyone works from home, and from different locations around the world. I have been involved in all the interviews/recruitment and all that actually matters is whether the person would enjoy working with the company.

    One of the only requirements I insist on (you can use any OS,IDE etc) is to feel free to ask me as many questions about the business/code/networks etc whenever you're uncertain or simply intrigued. I will always make time to answer.

    What I've found is that *everyone* on the team has a similar attitude. Whether it's because I'm "leading by example" or simply lucky, the point is that that's how it should be and I would not accept a job where that wasn't the case.

    Nothing is more important than the people you are working with and if they can't be helpful then it's probably not worth staying there. Remember that you're deciding which group of people you're prepared to spend most of your waking life working alongside.
  • JJ 2012-09-17 15:02
    Orv:
    To borrow the airplane analogy, the guys driving rivets or assembling engines at Boeing don't learn how to fly a 747 as part of their training. It'd be a waste of everyone's time, because what they really need to understand is the little piece they're working on.

    Well, perhaps my reading comprehension isn't as good as I thought, but I didn't get from the article that S.N. wanted to learn how to fly the 747. Let me borrow your borrowed analogy:

    Bob the new riveter has just arrived on the job. He was told by his supervisor to put 4 mini-mushrooms on every engine at so-and-so location. The problem is, Bob has no idea what a "mini-mushroom" is (let's pretend it's a .5" rivet), and no one will tell him. He's just expected to figure it out on his own.

    That's how I understood S.N.'s situation, and I think it's unforgivable. If your company uses jargon, you need to EXPLAIN it to the new people.
  • cici 2012-09-17 19:15
    Alex, it hasn't changed much since then. I just spent five weeks at a bank in their loan retention department doing *nothing*. It took two weeks just to get my dev environment set up. I was assured by a friend who'd worked there for many years that no one individual would be able to affect changes. The bank knew they needed to fix their processes to become more efficient. They were in the first year of a three year plan to accomplish that.

    I ran.
  • bjolling 2012-09-18 08:34
    Cbuttius:
    Ok: on wikis you can create a link by putting square brackets around the term.

    Edit the wiki page if you are able and put square brackets around each term that needs describing.

    Note that the link will probably not exist yet, but in time it will be populated.

    Once I was a young and naive developer just like you
  • Steve Chastain 2012-09-18 09:28
    Respectfully, I'm an IT consultant in the software arena and would like to ask you a question. I was wondering if anyone had done any research/article on buying mathematical algorithms vs. programming them yourself? Especially for complicated mathematical subroutines, is it cost effective to subscribe to an algorithm library (like www.nag.com) for about $3000 per year, or let your programmers do all the work? Have you ever offered an opinion on this subject? If any of your readers have any experience buying an algorithm vs. programming, I'd appreciate hearing about it.
    Thanks, Steve Chastain
    stevepuffin@yahoo.com
  • Phil McKracken 2012-09-18 15:16
    One job I waited 3 weeks before someone got me something to do. Most have at least 1 person that knows it all and doesn't share. In my case I fixed the grid so I could select a row, what I didn't know was that my boss had told people in emails that there was noway to do it.

    Perform your job well and learn to love looking at 4 cube walls for the next 30 years. If your lucky you cube mates will be nice but don't count on it.
  • Hard-working lazy-ass 2012-09-19 05:25
    Too long; still didn't read.

    Filed under: DIDN'T READ LOL, lol
  • dovahpants 2012-09-20 10:35
    Then you took an arrow in the knee?
  • luso 2012-09-21 11:26
    This guy must be working in the same company I do!
  • Cindy Crosby 2012-09-21 14:37
    Don't dispair, it takes awhile (min. 1 year) to start to get comfortable with large systems. One piece of advice however- if you find yourself working with a moderately pleasing to the eye Russian/Azerbijani woman who turns out to be the devil incarnate, follow Christopher's Cross' advice and Ride Like The Wind outta there!
  • Infini7y 2012-09-22 17:28
    +2 Assignment or Objective driven with 'what is the next step', best advice. (and keep a written journal).
  • Infini7y 2012-09-22 17:30
    morfizm:
    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!


    +2 Assignment or Objective driven with 'what is the next step', best advice. (and keep a written journal).
  • AN AMAZING CODER 2012-09-26 23:33
    I'm the CTO of a small startup tech company, and even I can know this pain. My advice is that you SHOULDN'T try to understand everything. I practice this even at my current company. There's so many facets to the market we're trying to reach that I have to choose the information that's most important to pass down to my team, rather than make room for filling them in on everything. Focus on the information most important to creating the most output, not in trying to fully understand the entire picture.

    Rocket science is hard, but understanding what rockets do is easy. And landing on the moon is much easier when you let everyone else do their job, and you focus on yours.