Jr. vs Sr. Developers

[Timothy High]

Hey folks,

I was just about to write a blog post off the top of my head about something I think is kinda important. But then I thought I might be jumping the gun a bit here, so I turn to you with an informal non-academic survey:

Can you think of any examples that clearly show the difference between how an experienced developer and a junior one attacked a problem? I'm looking mostly for anecdotes, but any information will do (especially if there are in-depth studies out there). I'd like to get some very specific examples, like the one below:

-------------------------

Problem:

Something is resizing my images until they're teeny-tiny

Jr. Dev solution:

1) Test screen width

2) If < 600, use Javascript to re-resize image

Result: kinda works for the target client, but nowhere else.

Sr. Dev solution:

After some code investigations, a meta tag we'd never heard of before caught my eye. Turns out it was causing the resizing. Proper configuration of the tag fixed the problem.

--------------------------

I've also had people just send me little quips like the ones below that I also find helpful:

* When I was a starting developer I always made my own frameworks. Now I look around before I go that route.

* As a jr developer I would love to rewrite existing code because I thought I could do better. Now I agree more with the 'if it ain't broke, don't fix it' philosophy.

I didn't find anything like this, so maybe when I'm done, this will be my belated contribution to the 97 Thing Programmer project. At any rate, I think it makes for an interesting discussion.

Thanks for any contributions you have!

Tim.

[Thomas Guest]

Hi Timothy,

I think you have some great material and ideas here. Please ping this
list again when you've finished your post -- I've stopped checking the
site for updates.

I enjoy the anecdotal "things". For me, the book could have done with
more of these. Your story about resizing images rings very true. It's
a specific example of the general point you want to make, but I think
you should concentrate on the specifics, and allow the reader work out
the general point.

In other words, why not flesh out the story? I think it would fit the
97 Things format very well.

(Now you've mentioned it, I've remembered a similar tale from the code
face, which I must write up some day. It involved a developer, a Linux
post install script, and lots of DVDs ending up in the bin.)

Anyway, these are just my thoughts,

> --
> To view or edit your contributions, visit
> http://programmer.97things.oreilly.com
> To post to this group, send email to 97things-...@googlegroups.com
> For more options, visit this group at
> http://groups.google.com/group/97things-programmer?hl=en
>
> To unsubscribe from this group, send email to
> 97things-programmer+unsubscribegooglegroups.com or reply to this email with
> the words "REMOVE ME" as the subject.
>

--
Thomas Guest
http://wordaligned.org

[Niclas Nilsson]

On Fri, Mar 26, 2010 at 2:10 PM, John T Davies <Jo...@johntdavies.com> wrote:

> ... I guess the delta between day one and day two, the bad programmer would still be using Eclipse on day two for example. :-)

You could generalize that: "...the bad programmer still be using an IDE." ;-)

Kind regards

Niclas

[Timothy High]

Thanks everyone!

If you have any more, let me know. 

@Thomas, I agree that the details are the most interesting part. But, like a bad director resorting to voice overs, I can't help but draw a conclusion in the end. If I get more anecdotes, I can turn it into a series, and leave the conclusions in the first post.

Any more anecdotes? The more specific, the better!

Tim.

--

[Jan Christiaan van Winkel]

* Timothy High (timoth...@gmail.com) [100326 02:29]:

> Can you think of any examples that clearly show the difference between how
> an experienced developer and a junior one attacked a problem? I'm looking
> mostly for anecdotes, but any information will do (especially if there are
> in-depth studies out there). I'd like to get some very specific examples,

The junior developer will hack away on live systems late at night to
add some new feature and then find out the next morning (afternoon?)
that his brain wasn't working that brilliantly at 3am causing the
system to crash. Of course no copies of the working version were
kept, so the users of his system are tearing their hairs out while the
programmer is trying to repair what he damaged.

The experience developer uses some version control system so that he
can allways find out what was changed by whom and why, and allows him
to retrieve olders versions of the software, should that be necessary.

JC

--
___ __ __________________________________________________________________
|/ \
| Jan Christiaan van Winkel j...@oreo.nl
__/ \__/ __________________________________________________________________

[Michael Loukides]

This is an interesting discussion. If anyone wants to package it up and put it on a 97 Things blog, that would be great. You could even post it on answers.oreilly.com.  

Mike

On Mar 30, 2010, at 10:24 AM, Richard Monson-Haefel wrote:

This is what I believe is the essential difference between a Junior programmer and a Sr. Programmer.  

Sr. Programmers not only believes they are fallible, they are certain they will make mistakes and so the Sr. Programmer takes precautions to limit the impact of those mistakes. The Jr. Programmer does not take these precautions. 

On Tue, Mar 30, 2010 at 4:00 AM, Bill de hOra <bi...@dehora.net> wrote:

A junior v senior distinction is a red herring.

Bill

Braithwaite, Keith wrote:

The experienced developer won't hack on live systems under any circumstances, nor do any work at 3 am.
________________________________________
From: Jan Christiaan van Winkel [j...@oreo.nl]
Sent: 29 March 2010 18:50
To: Timothy High
Cc: 97things...@oreilly.com; 97things-...@googlegroups.com
Subject: Re: [97things-programmer] Jr. vs Sr. Developers

[Michael Loukides]

There could be. For most situations, I think we probably get more mileage out of you guys maintaining your own blogs and talking about the book: for the most part, you're fairly well known in the industry, and I've always thought that spreading the word about the book through diverse sites is more effective than concentrating everything in one place. 

But for something like this, which has been a sustained discussion, if we post it, we'd want to put it into one place. Again, it could be answers.oreilly.com, which isn't a blog, but could maintain the conversational flow.

Or we could probably post it on O'Reilly Radar. 

Or Mac Slocum, who's now edits our websites, may have some other ideas. 

Mike

On Mar 30, 2010, at 10:30 AM, Braithwaite, Keith wrote:

There’s a 97 things blog?

 

---

From: Michael Loukides [mailto:mi...@oreilly.com] 
Sent: 30 March 2010 15:28
To: Richard Monson-Haefel
Cc: Bill de hOra; Braithwaite, Keith; Jan Christiaan van Winkel; Timothy High; 97things...@oreilly.com; 97things-...@googlegroups.com

Subject: Re: [97things-programmer] Jr. vs Sr. Developers

[Paul W. Homer]

In my experience, I've often found that the younger programmers have always been way to quick to rush off and do something. Not that I think sitting around is a great idea, but sometimes a little 'thinking' can prevent a huge number of problems.

When I was young, I tended to think that the job was all about code. Somehow coding would solve all of the problems, if only there is enough code. Code, code, code. If only there were no bugs ...

In time, I realized that programming was only a small fraction of what was needed to really build a system for the users. It's important, but not the most important thing in achieving success.


Paul.

On Tue, Mar 30, 2010 at 4:46 AM, Braithwaite, Keith <k...@zuhlke.com> wrote:

It's bad management that results in a programmer needing or wanting to work on a live system at 3 am. And bad programming to do it. An experienced (where the experience has lead to learning, anyway) programmer doesn't want to work on live systems at  3 am and won't do so if asked.

At which point the bad manager will fire the experienced programmer for not being a "team player".

But I do think it's characteristic of inexperience programmers that they don't mind so much hacking on live systems at 3 am. They might even think it up themselves. They just aren't the only bad thing about the situation.

Keith

________________________________________
From: John T Davies [Jo...@JohnTDavies.com]
Sent: 30 March 2010 10:39
To: Braithwaite, Keith
Cc: Jan Christiaan van Winkel; Timothy High; 97things...@oreilly.com; 97things-...@googlegroups.com

Subject: Re: [97things-programmer] Jr. vs Sr. Developers

To be honest I'd have to question the manager rather than the
programmer if anyone's working on a life system or at 3am and has no
SCM system. That wouldn't be a programming issue at any level, that's
crap management and that's usually where crap programmers end up.

-John- (on the road or in the air)
Tel. : +44 7770697272
http://www.johntdavies.com
Twitter: @jtdavies
Skype: john-davies

On 30 Mar 2010, at 08:59, "Braithwaite, Keith" <k...@zuhlke.com> wrote:

> The experienced developer won't hack on live systems under any
> circumstances, nor do any work at 3 am.
> ________________________________________
> From: Jan Christiaan van Winkel [j...@oreo.nl]
> Sent: 29 March 2010 18:50
> To: Timothy High
> Cc: 97things...@oreilly.com; 97things-

> progr...@googlegroups.com

> Subject: Re: [97things-programmer] Jr. vs Sr. Developers
>

[Paul Homer]

Sure, in so long as you're not actually making the problem worse. Sometimes the quick short-term fix is a huge -1 in the long-term. Accrue enough -1s and the technical debt becomes impossible to break free from. You see this is all sorts of modern endeavors, for instance politicians making new laws each time something bad happens. Laws only work if people remember them and abide by their 'wisdom'. If there are too many, and they're not reasonable, then they are just gumming up the works instead of making things better.  We live in a stupidly complex world that is only getting more stupidly complex. Paul. --- On Tue, 3/30/10, John T Davies <Jo...@johntdavies.com> wrote:

From: John T Davies <Jo...@johntdavies.com> Subject: Re: [97things-programmer] Jr. vs Sr. Developers

To: "Paul W. Homer" <paulw...@gmail.com> Cc: "Braithwaite, Keith" <k...@zuhlke.com>, "Jan Christiaan van Winkel" <j...@oreo.nl>, "Timothy High" <timoth...@gmail.com>, "97things...@oreilly.com" <97things...@oreilly.com>, "97things-...@googlegroups.com" <97things-...@googlegroups.com> Received: Tuesday, March 30, 2010, 10:40 AM Enthusiasm is a valuable trait though, inexperienced pragmatism over professional procrastination any day. -John- Tel.: +44 7770697272 twitter: @jtdavies Web: http://www.lightinimages.com

---

The new Internet Explorer® 8 - Faster, safer, easier. Optimized for Yahoo! Get it Now for Free!

[Timothy High]

I'd like to take a time out in the thread to thank everyone that's responded so far! It's not too late to contribute more anecdotes - I haven't had time yet to finish the post.

@Bill de hOra - I think I know what you're getting at, but like I said, this isn't an academic study, and I'm not really interested in politics nor semantics. I'm more interested in what we know or "feel" through our experience: that experience makes a difference in the way we think. And I'd like to do that through actual examples, if possible.

As for a 97 things blog, the thing about blogs is that each author likes to have their own corner, and to some degree "brand" themselves. But it might be interesting to have an official place for "97 Things" thoughts - I guess the distinctive character would be that it relates to the subject of the books, and that it's more of a "collective" post - someone's thoughts, and then group reactions. Perhaps.

As I mentioned at the beginning, my idea would be to post this on my blog, but also turn it into some sort of 97 Things - Programmer axiom.

Tim.

On Tue, Mar 30, 2010 at 11:40 AM, John T Davies <Jo...@johntdavies.com> wrote:

Enthusiasm is a valuable trait though, inexperienced pragmatism over professional procrastination any day.

-John-

Tel.: +44 7770697272

twitter: @jtdavies

Web: http://www.lightinimages.com

On 30 Mar 2010, at 15:35, Paul W. Homer wrote:

[Steve Berczuk]

This is a great point... If I had to make a sweeping generalization,
I'd say that the more experienced (good) programmers are more aware of
what they don't know, so will opt to work more collaboratively, and
use scaffolding like unit tests and SCM to allow room for errors.

While this sounds like "slower and more cautious" it's not really...
more often that not, the "experienced" approach gets things done
right the first time, and when there is a problem, it causes less down
time.

Having said that, "years working" doesn't always map to to this kind
of self-reflection. (and some work environments reward the
late-nite-solo hero type of work style so people of all levels will be
practical and do what's rewarded....)

These are all generalizations of course :)

Steve

On Mon, Mar 29, 2010 at 12:50 PM, Jan Christiaan van Winkel <j...@oreo.nl> wrote:
> * Timothy High (timoth...@gmail.com) [100326 02:29]:
>> Can you think of any examples that clearly show the difference between how
>> an experienced developer and a junior one attacked a problem? I'm looking
>> mostly for anecdotes, but any information will do (especially if there are
>> in-depth studies out there). I'd like to get some very specific examples,
>
> The junior developer will hack away on live systems late at night to
> add some new feature and then find out the next morning (afternoon?)
> that his brain wasn't working that brilliantly at 3am causing the
> system to crash.  Of course no copies of the working version were
> kept, so the users of his system are tearing their hairs out while the
> programmer is trying to repair what he damaged.
>
> The experience developer uses some version control system so that he
> can allways find out what was changed by whom and why, and allows him
> to retrieve olders versions of the software, should that be necessary.

--
Steve Berczuk | steve....@gmail.com | http://www.berczuk.com
SCM Patterns: Effective Teamwork, Practical Integration
www.scmpatterns.com

[Chuck Allison]

Another distinction: juniors are quick to do things because they're "cool", whether they're needed or not. I've seen new C programmers do everything with pointers instead of arrays when they learned pointers. I once reviewed some code which called for a few loops, but the programmer did everything recursively - in C! I convinced him to change back to loops. Some students in my Computation Theory class use classes and objects with the small assignments I give them when just a few functions or a few lines of code will do (which makes them harder to grade).

Seniors are more likely to do the simplest thing. They're not out to impress people. It's important to experiment in order to learn, but not without  need in production code!

-- Chuck

[Timothy High]

Good one! And totally different from my original focus. I think if we try to cover all the differences, it'll end up being another 97 Things book of its own (or a rehash of the first), but I think it's great to be getting concrete examples.

I'm also reminded of some recent examples where the newer programmers on my team just didn't adhere to the requirements the way you'd expect. There were a couple of ways I saw diversions from the requirement:

1) They didn't take the requirement as "law": the implementation diverged from what was requested in some way, either because it wasn't read very carefully (they skipped some menu items, forgot to use the security hooks, didn't change the text as requested, or something to that aspect). Just about every issue marked as ready was rejected maybe 2 or 3 times by me after just a quick glance at the work, which means there was also a certain carelessness with the way work was handed over.

2) They sometimes invent their own requirements: perhaps because of an offhand comment "maybe we should add a search bar here - naaah" or because they'd seen it done some way before, or just thought it was a "good idea", I saw things implemented that were never part of the deal, and had to be ripped out.

3) They didn't understand the intent behind the requirement: this is a bit contradictory to the previous statements, but there were times when the requirement itself was incomplete, and because something was omitted from the written statement, it wasn't done (and wasn't even questioned). For example, we wanted to disable user self-registration from our portal platform, and a couple of links were specifically listed, but one obvious link on the log in page itself was left in just because it wasn't on the list.

There are a lot of different reasons why this happens, but I could boil some if it down to:

* Impatience

* Lack of experiences with the consequences of not getting it "right" (rework, team and client frustration, and so on)

* Lack of understanding what it means to get it "right", in part because of a:

* Lack of understanding of what exactly a requirement is (an imperfect expression of the client's desire, tempered by constraints, as opposed to just a statement of work to be done)

Tim.

[Chuck Allison]

Ha!

That reminds me of a freshman student who obviously skated through secondary school, because he thought he knew everything and thought completing all the details of an assignment were beneath him. In a beginning C++ class he persistently did only a portion of the assignments because the stuff he didn't bother to do was "unimportant" (just "details"). I'm not sure he ever got the idea that those who pay us decide what they want, not us.

This could also get us into a discussion of how some gifted left-brainers skim the surface and are the last to mature in life, but let's not go there :-). I happen to know this from experience because I was a math major and was methodically taught to be lazy (just grasp the concept - everything else is "just details" for engineers or other low-lifes to grapple with :-).

[Greg Colvin]

What comes to mind first is the saying:  "Good judgment comes from experience, and experience comes from bad judgment."

So the problem when managing junior programmers is to keep their bad judgment from damaging the enterprise, and in some of the anecdotes so far I would not blame the junior programmer.

The upside of junior programmers is that they can't judge what's impossible, and therefor do it sometimes.

E.g. some years back our team at Oracle had submitted plans to write a just-in-time compiler for our Java system.  The plans would have kept most of our team busy for a year, and management said NO, Java performance isn't worth that much to us.  Then we hired a puppy.  He looked at our plans, saw a much simpler solution, and quietly implemented it on his own time evenings and weekends.  Thus rendering my own work to speed up the interpreter useless...

[Steve Berczuk]

much like all "Experience" (in the sense that we are talking: "being
able to do good things") and "time spent programming" aren't always
correlated, seeing possibilities isn't always correlated with lack of
experience.

Anecdotally, the programmers I know who really embrace agile
(including the testing and refactoring practices and the philosophies
of transparency and being willing to fail) tend to be more willing to
try naive and simpler approaches... and sometimes they work.

I'm wondering if the "experienced v junior" dichotomy we're speaking
of is actually misleading....

Following up Michael's comment about how to discuss this and spread
the 97 things word, maybe Timothy should just blog something, and
anyone who has something longer to say can blog as well, and put that
link in a comment to the original?

--

[jason...@jegas.com]

At risk of sounding like a killjoy, can you guys find another thread to
discuss this "new book" about juniors and senior coders?

I'm on this mailing list exclusively for the "97 Things Every Programmer
Should Know" book we all collaboratively wrote with O'Reilly and Kevlin
Henney.

I feel that this mailing list was created for news and information
pertaining to that effort. If I'm mistaken, I'll just unsubscribe - no
worries. Kevlin has email and I'm easy enough to locate.

Thank you.

Regards,
Jason P Sage

Jegas, LLC
9 West Road FL#1
Ellington CT, 06029
http://www.jegas.com - Home Page
http://www.jegas.net - Hosting, Domain Names, Email etc.
http://www.linkedin.com/in/jasonpsage - Linked-In Profile

860-871-6691 Home Office
860-338-4565 Mobile

This communication, including attachments, is for the exclusive use of
addressee and may contain proprietary, confidential and/or privileged
information. If you are not the intended recipient, any use, copying,
disclosure, dissemination or distribution is strictly prohibited. If you
are not the intended recipient, please notify the sender immediately by
return e-mail, delete this communication and destroy all copies.

-------- Original Message --------
Subject: Re: [97things-programmer] Jr. vs Sr. Developers

From: Greg Colvin <gr...@colvin.org>
Date: Tue, March 30, 2010 1:20 pm
To: 97things-...@googlegroups.com

What comes to mind first is the saying: "Good judgment comes from
experience, and experience comes from bad judgment."

So the problem when managing junior programmers is to keep their bad
judgment from damaging the enterprise, and in some of the anecdotes so
far I would not blame the junior programmer.

The upside of junior programmers is that they can't judge what's
impossible, and therefor do it sometimes.

E.g. some years back our team at Oracle had submitted plans to write a
just-in-time compiler for our Java system. The plans would have kept
most of our team busy for a year, and management said NO, Java
performance isn't worth that much to us. Then we hired a puppy. He
looked at our plans, saw a much simpler solution, and quietly
implemented it on his own time evenings and weekends. Thus rendering my
own work to speed up the interpreter useless...

On Mar 25, 2010, at 7:28 PM, Timothy High wrote:

Hey folks,I was just about to write a blog post off the top of my head

[Timothy High]

My experience from the 97 Things Architects list is that the list is a community as well as a place for news and events. That's the way we've been using it ever since. If more people echo these sentiments, perhaps it's worth creating separate lists for the two purposes.

[Timothy High]

Well, this is one of those things in life (or really philosophy) where your opinion can keep flip-flopping the more experienced (or jaded) you become. I went through a "two kinds" phase in life, then I went through a "no kinds - categories are all false" phase, now I'm at a "come on, you really know deep down what I'm talking about" phase. To give a little foreshadowing of my blog, I was reminded of the Smith System of safe driving I was taught as a beginner: http://www.smith-system.com/ Sure, no two drivers are alike, but there's a natural evolution from beginner's driving habits to mature driving habits. So what are those, and is it just a "97 Things" set of advice, or is there really a change in the way a programmer tackles the problem itself?

On Tue, Mar 30, 2010 at 2:29 PM, David Ing <davi...@gmail.com> wrote:

>+1 Bill i.e. 'A junior developer will try to find arbitrary criteria to create a misleading classification of developers, in that they always mysteriously end up on top' :)

Corollary: Finding no humor in the last statement is a sign of a Junior developer.

As I've got email replies from someone who has taken my last response as a personal insult (I checked, they really did, so I apologized) then let me expand on why I think it's the exercise is a red herring. Disclaimer: If I disagree with you that doesn't mean I'm insulting you (see corollary above).

I am personally uncomfortable with dividing people into classifications of junior and senior developers because often it comes down to a 'young vs old' set of observations where years of experience is the yard-stick. That may well be true (I'm old, so I'd think that), but is potentially divisive in that a junior developer can now not be taught what exactly makes the difference, other than years spent. 

Put another way, if we end up with 'when you're older' truisms that make what we do descend more to magic than practical processes, which veers too much towards the 'unteachable craft' than I'd prefer. (I am not saying here that all that was offered was truisms, just more an observations that classifications tend to end up that way).

Someone bright and talented straight out of college should be able to be a senior developer, as I believe (or maybe want to make true) that what we do is based on pure talent and learning, and not mileage or dogma that can't be taught. 

As harsh as it sounds, it *is* true than any classifications do tend to be arbitrary and that it is nearly always the case that those making the rules tend to use themselves as the bar to pass. Junior sounds too much like an insult. I think it all comes down to this:

http://martinfowler.com/bliki/CannotMeasureProductivity.html

PS The exercise is still fun to do though, despite my grumpiness.

David Ing

On Tue, Mar 30, 2010 at 9:26 AM, David Ing <davi...@gmail.com> wrote:

+1 Bill i.e. 'A junior developer will try to find arbitrary criteria to create a misleading classification of developers, in that they always mysteriously end up on top' :)

David Ing

On 2010-03-30, at 2:00 AM, Bill de hOra <bi...@dehora.net> wrote:

A junior v senior distinction is a red herring.

Bill

Braithwaite, Keith wrote:

The experienced developer won't hack on live systems under any circumstances, nor do any work at 3 am.
________________________________________
From: Jan Christiaan van Winkel [j...@oreo.nl]
Sent: 29 March 2010 18:50
To: Timothy High

Cc: 97things...@oreilly.com; 97things-...@googlegroups.com

Subject: Re: [97things-programmer] Jr. vs Sr. Developers

[Greg Colvin]

Don't forget Robert Benchley’s Law of Distinction: “There are two kinds of people in the world, those who believe there are two kinds of people in the world and those who don’t.”  And the retort that "There are two kinds of people in the world, those who believe there are two kinds of people in the world and those who believe it's not that simple.”

[Paul Homer]

I'd add "structure" into the second type of skills. At first coding is about getting some large set of instructions to run. Later, it is about getting them to run AND getting them to be easier to read. And even later, it is about getting them 'well-structured' so that it doesn't turn ugly when it grows. As one gains in experience, the context of the work and many of the desired attributes for the code grow as well. In-experienced programmers usually suffer from tunnel vision (and often hubris, since they think what they see is 'everything'). Paul. --- On Tue, 3/30/10, Dan Chak <d...@chak.org> wrote: From: Dan Chak <d...@chak.org> Subject: Re: Jr. vs Sr. Developers To: "Timothy High" <timoth...@gmail.com> Cc: 97things...@oreilly.com, 97things-...@googlegroups.com Received: Tuesday, March 30, 2010, 5:03 PM I would make a distinction between the following two types of skills:  First, those which you should learn in school, but which they didn't teach you, and consequently you should learn on the job.  And second, those which experience may make you good at, but also may not. In the first set of skills, I would put items like source control management, documentation, unit testing, staggered environments for development, staging, production, etc.  Everyone has the capacity to learn how these things work and work with them; it's more a matter of company policies and peer education than of the competency of the developer herself.  You can write a cheat sheet or how-to for these things.  If someone isn't doing them I would blame the shop, not the individual. The second set of skills are much higher level, and revolve around planning, designing, and executing.  I have watched competent developers -- who have the first set of skills in spades -- drop the ball on problems that had the potential to be simple tasks due to a lack of appreciation for the following four skills: 1. Forecasting.  Be a good estimator of the effort required to complete a task, and especially how long different approaches might take.  The goal is not to impress with the speediness your estimates, but to be accurate and dependable.  Have you figured out all of the unknowns before you started down your path?  Often the solution that is best understood will be the appropriate one. 2. Risk mitigation.  Some solutions are easier to implement than others, even if they are not as elegant.  Many different elements of coding have consequences: the algorithm efficiency, the number of external dependencies, how easy or hard it is for QA to test, and also the efficiency of producing the code itself.  Regarding the time tradeoff, often shaving a millisecond or two off an algorithm doesn't warrant delivering a product late.  You're proud of your solution, but meanwhile your team or your boss is hung out to dry for being late. 3. Recognizing dead ends.  A junior developer will try various combinations of logic, cutting, pasting, etc, right up to the buzzer.  He hopes that things will magically fall into place, but when this happens, it's more likely that the planned solution wasn't fully understood in the first place.  Then there is a laundry list of paths that didn't work as expected given as excuses for the missed deadline.  The senior developer wonders why any of these paths were part of the solution at all.  Long before the buzzer rang, the developer should have: a) gone back to the drawing board, b) picked one of the simpler solutions from (2) above and continued, or c) asked someone else for help or advice. 4. Knowing where to look for answers.  Often I find people get stuck on something that is easily answered with a Google query.  They have submitted a ticket to the developers of some third party library and are twiddling their thumbs waiting for an answer, happy to have passed the buck on to someone else.  Then you show them that pasting the error into Google provides immediate satisfaction. In a nutshell, the senior developer has a context of the software's purpose within the larger organization, and makes decisions based on business outcomes as much as anything else.  The fundamental problem is to align every developer's goals with the goals of the business. Dan Chak http://enterpriserails.chak.org

On Mar 25, 2010, at 9:28 PM, Timothy High wrote: Hey folks, I was just about to write a blog post off the top of my head about something I think is kinda important. But then I thought I might be jumping the gun a bit here, so I turn to you with an informal non-academic survey: Can you think of any examples that clearly show the difference between how an experienced developer and a junior one attacked a problem? I'm looking mostly for anecdotes, but any information will do (especially if there are in-depth studies out there). I'd like to get some very specific examples, like the one below: ------------------------- Problem: Something is resizing my images until they're teeny-tiny Jr. Dev solution: 1) Test screen width 2) If < 600, use Javascript to re-resize image Result: kinda works for the target client, but nowhere else. Sr. Dev solution: After some code investigations, a meta tag we'd never heard of before caught my eye. Turns out it was causing the resizing. Proper configuration of the tag fixed the problem. -------------------------- I've also had people just send me little quips like the ones below that I also find helpful: * When I was a starting developer I always made my own frameworks. Now I look around before I go that route. * As a jr developer I would love to rewrite existing code because I thought I could do better. Now I agree more with the 'if it ain't broke, don't fix it' philosophy. I didn't find anything like this, so maybe when I'm done, this will be my belated contribution to the 97 Thing Programmer project. At any rate, I think it makes for an interesting discussion. Thanks for any contributions you have! Tim.

---

Make your browsing faster, safer, and easier with the new Internet Explorer® 8. Optimized for Yahoo! Get it Now for Free!

[Sarah Mount]

Yes, this echoes with my experience too, and as someone else has said
further down down the thread, half the problem comes with newbies not
having made enough damn mistakes before they get to you. Common ones I
see all the time are probably familiar to everyone -- testing doesn't
matter (it can come "later"), documentation doesn't matter (it's for
idiots anyway), anything can be done badly because it can be
refactored after, the IDE *told* me to do $X, ... . The most
frustrating problems come from the issue Chuck raises, i.e. not seeing
the big picture. Once a newbie has reimplemented a whole system
(because, you know, reading the manual is too much like hard work)
then all the work around the old system either falls apart or needs to
be rewritten at great expense to someone else.

A common thing I've been seeing in class recently, and may write up if
I get a chance, is to do with algorithm design and IDEs. The IDE (with
"intellisense" or equivalent) will hint how to fix your code for
compilation, but this will often break a sensible algorithm. For
example:

createSocket(); // throws IOException
sendStuffDownSocket(); // throws IOException

can easily be turned into

try { createSocket(); }
catch ...
try { sendStuffDownSocket(); }
catch ...

sans keyboard with a few mouse clicks, and then if you can't create a
socket, you try to send data down it anyway. This is much worse when
your IO code is wrapped in a loop, as it will be in a server class.
:-(

Cheers,

Sarah

--
Sarah Mount, Senior Lecturer, University of Wolverhampton
website: http://www.snim2.org/
twitter: @snim2

This email, together with any attachment, is for the exclusive and
confidential use of the addressee(s) and may contain legally
privileged information. Any use, disclosure or reproduction without
the sender's explicit consent is unauthorised and may be unlawful.

Any e-mail including its content and any attachments may be monitored
and used by The University of Wolverhampton for reasons of security
and for monitoring internal compliance with the University's policy on
internet use. E-mail blocking software may also be used. The
University cannot guarantee that this message or any attachment is
virus free or has not been intercepted and amended.

If you believe you have received this message in error please notify
the sender by email, telephone or fax and destroy the message and any
copies.

[George Brooke]

Hi,

Just to throw a small spanner into the discussion, in some fields progress
is made because the newbies just do not know that something cannot / should
not be done. So, they go ahead and do it, whilst the wise old heads advise
against. Thus progress (not all progress) is made. I am not sure if this
approach works at the micro level of the examples that I have seen so far in
this conversation (which have been limited to programming), but it does seem
to work in the sciences. Perhaps it is more applicable at macro-level...
producing things like Google etc?

George

Oak Lodge Consulting Ltd
20 Back Road
Linton, Cambridge
CB21 4JF

Tel: 01223-890390; Fax: 0870-7063077
VoIP: 01223-750016; Mbl: 07710-325818

www.oaklodgeconsulting.co.uk

This e-mail may contain confidential and/or privileged information. If you
are not the intended recipient (or have received this e-mail in error)
please notify the sender immediately and destroy this e-mail. Any
unauthorized copying, disclosure or distribution of the material in this
e-mail is strictly forbidden.

[Niclas Nilsson]

ID Software (Wolfenstein 3D, Doom, Quake) springs to mind. They didn't
know it was impossible to write a 1st person shooter game due to
performance, so they went ahead and did it.

Kind regards
Niclas

[Paul W. Homer]

I think Wolfenstein was inspired by some of the demos at the time, and definitely the great games that there available for the Amiga. Although it died as a platform, the Amiga shot way far ahead in terms of cool graphics and 3D games.

What made Wolfenstein interesting is that is was available for the PC, which in those days was a still very character centric and very behind the times. Amiga, Atari and Mac all had fancy GUIs (not to mention Sun Workstations and NeXT).

Wolfenstein is a great example, because I think the same guys basically rewrote the same engine over and over again, making it better each time. There were some great papers available that explained how they short-cut the math, so they could calculate fast enough given all of the CPU limitations. These days, that stuff has all moved to graphic pipelines on cards.

It's not that Jrs won't go there, it's just that the approach is different from a person with more experience (which may or may not be a good thing).

Paul.