Discussions

News: Rafe Colburn: Starting at the bottom

  1. Rafe Colburn: Starting at the bottom (15 messages)

    Rafe Colburn, in "Starting at the bottom," says that most industries have mindless beginner tasks that serve as an apprenticeship, but software development does not. He ends up wondering if software development just might not be interesting enough to attract people who might have to be apprentices.
    ... If you want to be a plumber, or a carpenter, or an electrician, you generally have to go through an apprenticeship where you do lots of mindless manual labor, get coffee, and generally pay your dues and learn by osmosis until you've gotten to a point where the experienced people want to teach you anything. What I find interesting is how the software business breaks from this sort of approach. Most software developers start out at their first real job developing software. They may not get to do much design or work on the most interesting problems, but even that's not always the case. There are other areas where entry level programmers start out (like quality assurance), but by and large from day one programmers are applying the skills of their profession to solve real problems. Certainly there's no real concept of "dues paying" in software development. I can't help but wonder why that is. Is it that as a profession, software development isn't interesting to enough people that we can afford to mistreat newcomers in hope of weeding out the people who aren't really devoted?
    There are other industries that don't really have apprenticeships, of course, and Mr. Colburn's use of carpentry or plumbing is interesting, since many people would say that those industries aren't interesting enough to attract people despite an apprenticeship. But it's an interesting question: why doesn't software development have an apprenticeship, and would our profession be served better if there was such a thing?
  2. why doesn't software development have an apprenticeship, and would our profession be served better if there was such a thing?
    The software industry would best be served if teams with newbies in them have an appropriate ration of newbies to experienced and highly skilled developers. The skilled, seasoned developers can then act as "mentors" of sorts to the newbies, helping them learn quicker and catching their "newbie mistakes". The biggest detriment of the software industry is by far the "career path" of many organizations: the minute a developer shows some skill and talent, he is promoted upwards, eventually into management, rather than being properly rewarded for what he is really good at. At the same time companies and projects tend to overload development teams with a bunch of green graduates with little to no experience, and not much in the way of guidance from more senior developers available. So in summary, two things are needed: - Better newbie to experienced developer mixes on projects. - Good developers being rewarded for being good developers, rather than being promoted to their "level of incompetence". There is no substitute for experience and skill, and those can only be developed by actually getting the experience, not by getting coffee. / Wille Blog: Buzzword Bingo
  3. I guess this guy never worked in the places I worked. All of those places had entry level positions that the new guys got put on. "Hello, Welcome to the team! You're just in time to dive in to our i18n and l10n effort. In fact, we want you to identify, catalog, and codify all of the strings and messages in our 1M lines of code." "Hello, Welcome to the team! You're going to start today with Frank, who's going to teach you the build and release process as quickly as possible so he can move on to something more interesting." "Hello, Welcome to the team! Our system has 500 different screens that need continual maintenance and updating. Here's the login to the defects and enhancements system. Look like only 100 issues opened so far for you..." "Hello, Welcome to the team! Turns out that Biff the sysop grenaded the datastore and we've lost the last 2 weeks of data. Thankfully we still have it on paper -- Fred here will show you how to key it in..." Every organization and IT department I've been in has some level of scut work that the new kids can be thrown at with little risk to the system, and as an "practical" introduction to interacting with the system, processes, and people. Bug fixing is a great way to introduce new folks to a code base.
  4. I guess this guy never worked in the places I worked. All of those places had entry level positions that the new guys got put on.

    "Hello, Welcome to the team! You're just in time to dive in to our i18n and l10n effort. In fact, we want you to identify, catalog, and codify all of the strings and messages in our 1M lines of code."

    "Hello, Welcome to the team! You're going to start today with Frank, who's going to teach you the build and release process as quickly as possible so he can move on to something more interesting."

    "Hello, Welcome to the team! Our system has 500 different screens that need continual maintenance and updating. Here's the login to the defects and enhancements system. Look like only 100 issues opened so far for you..."

    "Hello, Welcome to the team! Turns out that Biff the sysop grenaded the datastore and we've lost the last 2 weeks of data. Thankfully we still have it on paper -- Fred here will show you how to key it in..."

    Every organization and IT department I've been in has some level of scut work that the new kids can be thrown at with little risk to the system, and as an "practical" introduction to interacting with the system, processes, and people.

    Bug fixing is a great way to introduce new folks to a code base.
    That is damn funny! I was talking to a friend today. He has some newbies that he has to assign work to. He asked me what should he give them. "Easy," I said, "Everything you don't want to do. HTML, label changes, documentation, logging..."
  5. Bug fixing is a great way to introduce new folks to a code base.
    Some companies have permanent positions for bug fixing.
  6. Bug fixing is a great way to introduce new folks to a code base.


    Some companies have permanent positions for bug fixing.
    This is true and I think it's a huge mistake. In an organization that hires people with limited experience, it often means that some developers are assigned to new development have never worked with any real code. They will be creating the bugs that the permanent bug-fixers are fixing. To paraphrase one of my physics professors from college: it's good to learn from your own mistakes but really smart people learn from the mistakes of others. Developers should understand what it's like to fix broken code before creating new code. I learned a great deal about how to write maintainable code by working with unmaintainable code.
  7. One thing that makes software development different than plumbing or carpentry is the education required before getting a job. Software programming is more a profession along the lines of accounting, legal, medical, etc. I would not expect a therapist, for example, to spend months making coffee before practicing. Nor would I want him to. Craig Blitz http://craigblitz.com
  8. One thing that makes software development different than plumbing or carpentry is the education required before getting a job. Software programming is more a profession along the lines of accounting, legal, medical, etc. I would not expect a therapist, for example, to spend months making coffee before practicing. Nor would I want him to.
    I think you'd also not want him to come in and start doing the same thing an experience therapist does on day one with no supervision. Let's take a more poignant example. Say you are coming into the hospital for an emergency appendectomy. How would you like it if it was your surgeon's first day on the job out of school? I think people are focusing too much on grunt work. An apprenticeship is not just about paying dues. Paying dues is just historically what apprentices did in return for the time the masters and journeymen spent teaching them. Apprentice developers can pay their dues by doing developer tasks that are not especially desirable. The fact of the matter is that doctors do go through an apprenticeship as do lawyers and other professionals even when they come from a top school. I doubt many people in these professions step into the job and starts doing the work that an experienced professional would on day one. This industry is the only one that I know of where anyone thinks that makes any sense at all. I think a lot of that comes from the bloated sense of self-importance that developers had not that long ago. I remember when I came out of school I could pick from a number of jobs. I don't think that is the norm today.
  9. The fact of the matter is that doctors do go through an apprenticeship as do lawyers and other professionals even when they come from a top school. I doubt many people in these professions step into the job and starts doing the work that an experienced professional would on day one. This industry is the only one that I know of where anyone thinks that makes any sense at all. I think a lot of that comes from the bloated sense of self-importance that developers had not that long ago. I remember when I came out of school I could pick from a number of jobs. I don't think that is the norm today.
    There are a few causes. One is that little correlation has been shown between developer productivity and experience, while it has been shown that there is an order-of-magnitude difference between good and bad developers. I've even read studies about how many teams have "negative producing programmers," meaning they create more work that they produce, and this isn't necessarily correlated with experience. Another is that people can often get jobs on very small teams, sometimes just as an individual, and never get experience under someone truly skilled. Often times their only exposure is to someone who shouldn't be allowed near a compiler (or interpretter). Even if you start out with a bright programmer fresh out of school, make him maintain code that if he had written while in school he would have been kicked out of CS, pair him with the dolt who wrote it, have him watch the dolt get accolades from ignorant business managers for creating bug-ridden implementations of new requirements quickly and not holding release up with excessive testing, and what exactly is this young person going to learn? He's going to learn that quality doesn't pay, business managers are marks, testing is for people who miss release dates, and everything he learned about writing good software is going to hold him back in his career. He will think this because at this point he doesn't know any better. And one last thing - the few good people who might be around are far too busy dealing with the results of negative producing programmers to do any mentoring. Apprenticeships are a great idea if you can find a way to make sure new programmers are put with compentent experienced programmers. A large organization where there is a "social contract" between the employer and employee may be able to do this. I'm sure there are ones that do. But I think they are the minority.
  10. There are a few causes. One is that little correlation has been shown between developer productivity and experience, while it has been shown that there is an order-of-magnitude difference between good and bad developers.
    There was recently a study that surgical skill was much more correlated with the time the surgeon spends playing video-games than with their schooling and exam scores. I don't think anyone's going to argue that we should stop making doctors go to school or that they should spend their residency playing "Super Monkey Ball". My experience is that the developers with the most potential to be excellent also tend to very bad design decisions. The need to keep things simple as possible is a lesson that is learned with experience. It's also completely against the natural urges of a bright young developer.
    I've even read studies about how many teams have "negative producing programmers," meaning they create more work that they produce, and this isn't necessarily correlated with experience.
    I know this from experience and often these people are new developers that lack experience.
    Another is that people can often get jobs on very small teams, sometimes just as an individual, and never get experience under someone truly skilled. Often times their only exposure is to someone who shouldn't be allowed near a compiler (or interpretter).
    These are issues absolutely real and also contribute to issues and problems. It's a separate but related issue. We need good mentors. The dearth of good mentors doesn't change that need. I think a lot of this stems from the dotcom boom. If you could turn on a computer, you became a developer. A lot of people left for other industries but we still carry that baggage.
    Even if you start out with a bright programmer fresh out of school, make him maintain code that if he had written while in school he would have been kicked out of CS, pair him with the dolt who wrote it, have him watch the dolt get accolades from ignorant business managers for creating bug-ridden implementations of new requirements quickly and not holding release up with excessive testing, and what exactly is this young person going to learn?

    He's going to learn that quality doesn't pay, business managers are marks, testing is for people who miss release dates, and everything he learned about writing good software is going to hold him back in his career. He will think this because at this point he doesn't know any better.

    And one last thing - the few good people who might be around are far too busy dealing with the results of negative producing programmers to do any mentoring.
    The sad fact is that he or she will learn this sooner or later.
    Apprenticeships are a great idea if you can find a way to make sure new programmers are put with compentent experienced programmers. A large organization where there is a "social contract" between the employer and employee may be able to do this. I'm sure there are ones that do. But I think they are the minority.
    I don't disagree with what you say. I just don't think it makes sense to throw your hands up and do nothing. A lot of these issues are not going to be resolved until skilled people start speaking up and contradicting the nonsense that is thrown around as common sense in this industry by mangers and consultants. I can't count the number of times where I've said things in meetings that my peers agree with in private but almost none of them are willing to back me up in front of our boss.
  11. Sticking at the bottom[ Go to top ]

    Even if you start out with a bright programmer fresh out of school, make him maintain code that if he had written while in school he would have been kicked out of CS, pair him with the dolt who wrote it, have him watch the dolt get accolades from ignorant business managers for creating bug-ridden implementations of new requirements quickly and not holding release up with excessive testing, and what exactly is this young person going to learn?

    He's going to learn that quality doesn't pay, business managers are marks, testing is for people who miss release dates, and everything he learned about writing good software is going to hold him back in his career. He will think this because at this point he doesn't know any better.

    And one last thing - the few good people who might be around are far too busy dealing with the results of negative producing programmers to do any mentoring.
    The sad thing is that this doesn't just apply to newbies - I've worked at organisations (one, in particular, comes to mind) where experienced developers saw all these things going on, tried to 'raise the bar', but were eventually brow-beaten into lowering their standards to those of the few people who always met deadlines and never contributed anything to the forward progression of the company's development practices. This mainly happens because of ill-informed bosses (I refuse to use the word 'managers' when referring to such people) who know that the developers have families to feed an mortgages to pay and bully them into bad practices. I can't remember who said it, but I eventually applied the 'If you can't change your company, change your company' rule.
  12. I guess this guy never worked in the places I worked. All of those places had entry level positions that the new guys got put on.

    (amusing list of grunt jobs removed for space sake)
    Every organization and IT department I've been in has some level of scut work that the new kids can be thrown at with little risk to the system, and as an "practical" introduction to interacting with the system, processes, and people.
    I gotta agree with Will here. My first job was making minor tweaks to a bar code reading program that was part of a chip assembly line and if I failed, I'm pretty sure nobody would have noticed. But, when I did complete the task, it demonstrated to the people that hired me that I wasn't a total moron (which my mother-in-law may still debate to this day) and I got a slightly more complex assignment next. That's a form of apprenticeship and every organization I've been a part of in the 15 years since, both ones where I was hired and where I was doing the hiring, has done it the exact same way (with bug fixing being the most used introductory topic). ---Pete http://nerdguru.net
  13. I don't think this is that mysterious. The reason why software engineering doesn't have apprenticeships the way that plumbing and carpentry does is that programming is mainly a solo task. It is pretty much one person sitting at a keyboard banging out code. There isn't much for a second "apprentice" to do. The Pair Programming idea that was part of Extreme Programming attempts to address that. There are other thinks you can do as well, such as finding secondary tasks for the newbies to work on. My personal favorite is assigning new people to producing things like Javadocs. It won't hurt the code but will familiarize the newbies on how the system works. Not terribly exciting, but definitely educational.
  14. It was said that companies definitely do have entry level positions that are mostly monkey work and things that nobody else wants to do. They're great. I think it boils down to economics, though. An overseas graduate with no experience is relatively worthless, yet they can do the job well enough and make enough money for a company to demand their grossly below par H1-B salary. As much as I'd like to see everyone in the industry go through an apprenticeship to give them a little taste, and to weed out the losers who just plain suck at programming (despite their graduate and post-grad degrees), it's very unlikely to happen. We'll continue to see people who feel entitled to higher salaries, but who don't go a good job, think, or pay attention to quality. They'll get in bed with companies who no longer want to spend for lawyers for work visa transfers, and they will get raises and promotions to retain the indentured serv... er, employees, just so they can keep labor procurement costs down.
  15. What I find interesting is how the software business breaks from this sort of approach. Most software developers start out at their first real job developing software. They may not get to do much design or work on the most interesting problems, but even that's not always the case. There are other areas where entry level programmers start out (like quality assurance), but by and large from day one programmers are applying the skills of their profession to solve real problems. Certainly there's no real concept of "dues paying" in software development.
    Firstly, I disagree that this is always the case. My first job was entirely maintenance along with burning,stamping,mailing install CDs. Secondly, I believe the lack of a string apprenticeship model is the main source of the problems with Software and IT. Almost every really hard problem I have had to deal with was created by an inexperienced developer with too little supervision. Often these developers were considered to be 'geniuses' or 'golden-boys'. Maintaining old code should be a requirement of any software apprenticeship. I know it made me a much better developer much earlier in my career. In my experience many managers believe more inexperienced developers to be better than experienced ones. There's something to this because people tend to get stuck in their ways but that's a different problem. Now with all the outsourcing that goes on, nobody seems to want to hire inexperienced developers at all. The little apprenticing that did go on is being eliminated entirely in this model. At least in the US, that is. Maybe Indian development shops will build a real apprenticeship model and make developers in the US a distant memory by breaking the unending recycling of dumbass ideas the software/IT industry suffers from.
  16. Almost every really hard problem I have had to deal with was created by an inexperienced developer with too little supervision. Often these developers were considered to be 'geniuses' or 'golden-boys'.
    The curse of our industry is being able to create the preception of something working, although the code and design implementing it, could be replete with poor decisions and hacks. Often junior and / or poor coders manage to get something look like working, at least for the time being and be promoted from apprenticeship. Although, if someone bothered to lift the hood and look at the code, that would have told a completely different story. Unfortunately, in most organization, this kind of review or inspection does not take place, for number of reasons. Sometimes, it's simply not valued, because of the myopic view of software on the part of mangement. Often good programmers get "promoted" to management positions and there is no one available to play such roles.