If you can't explain WHY you are writing code, stop! If the why is not there, the what will not fit the why, and will never fill the need.

You can activate Microsoft Bob from Vista. just google search. Its kinda cool

When I first started my job, I was confused why we, the programmers, would be the ones talking to the business area and writing documentation for our projects. Afterall, I just graduated college which consisted of a teacher handing us an assignment, completing it, and making sure the end product was correct, never fully understanding why we were doing it in the first place (other than to become better programmers). After a few years at my job, I've understood that it's much easier to work on a project when you and the business area are on the same page. I find that I run into far less unforeseen problems in the future because all of the requirements were established from the very start. I'm glad our company has the programmers work this way.

I am 75%+ in agreement with you.

Unfortunately, there are times when it comes down to "The business said so". Particularly when it comes to UI design, sooner or later you have to let go of the wheel and just do what the designer says.

I don't see the problem with your first example conversation with the developer. He knows exactly what he's doing, and all the responses are correct, and the final answer is what you're looking for (what matters to the user). Whether someone comes up with that right away or after a few questions is irrelevant, either way they still pass your 60 second test. The problem doesn't arise until the developer can't tell you at all why a change request is being made.

By the way, will someone please tell Microsoft to fix THEIR sort order in Windows Explorer? Drives me absolutely nuts when outputting lots of log files.

One of your more relevant posts for coders.

Part of this comes from the need for a coder to stop worrying because they are coming up with a technical solution for a requirement which means they are closer to being done.

And, many developers are told "just write code to meet the requirements" -- it's the team lead or business analyst's job to know why the requirements are thus -- but in the meantime get that coder coding!!

Nevertheless, too many people are too anxious to start typing and get something done quickly.

@adrian you mean this
It turns out that there’s an entire functional copy of the 1995 Microsoft BOB operating system hidden inside of Windows Vista. BOB was supposed to be an ...
http://technabob.com/blog/2007/04/01/windows-vista-easter-egg-discovered/
HA HA

BTW great blog Jeff !

The addicts talk mentions 50% of software developers as addicts. Well there is another issue, it may go side by side with addiction and sometimes is the cause for that addiction, sometimes it is the sole reason why one became a coder. Just like some doctors (i.e. surgeons) are natural born butchers and killers, that transformed their "need for blood" to something good, beneficial for society, like treating people, and bringing them back to life. Same way some software developers deep inside are just natural dictators with extreme need to control and achieve absolute obedience/submission from somebody or something. And writing software is one of the socially accepted activities that such needs can be satisfied with, when coder has total control over and strict obedience of the machine. It may sound ridiculous, but that's true for some coders.

>>Software developers think their job is writing code. But it's not.* Their job is to solve the customer's problem

I disagree. There should always be a disconnect between business and tech to keep a healthy balance of interests (this is the core of MSF, and for a very good reason). Business interests do not always align with technical interests - so it should fall to the PM to distill this.

I know we don't live in a perfect world Jeff but it seems your job is pretty client-side/sales cycle - your post is indicative of this role's thought pattern (which I'm also a part of). However the best of teams also have people devoted to the technology to keep us mavericks in line.

I am afraid, I have to agree with the author. Here's the view from the business

http://dailysalty.blogspot.com/2007/09/focus-on-important-stuff-in-technology.html

and also linked in is a post about my bewilderment about agile and and and..

@ workaholicus,
Where'd you read all that?
Sounds interesting.

And Jeff, I have failed the elevator test several times, for example the boss will catch me researching commands for a batch script, which I somehow have to sum up to "fixing joe's printer".

Great read. - Keep up the good work.

There is nothing strange about the conversation you quote, and you'll find similar conversations in any field you care to name. "Why are you fixing this car?" "Because it's the next one on the list." "Why are you talking to this patient?" "Because she has an appointment." If you want to know what's wrong with the sort order in the datagrid, ask that.

Furthermore, many--probably most--developers have no need to explain their work to a layperson. You cannot, for example, summarize "a caching DNS server" for a lay audience's benefit on an elevator. That's fine. If you're working on one, the lay audience aren't your customers.

There's a kernel of truth in what you say, but the way you state it is both insulting ("think their job is writing code"--fah!) and limited to the very narrow world of consumer product design.

I think the point Jeff is making is that if you can't easily/quickly (with a little prompting) summarize what your working on means to the customer and how it benefits them then you are likely not working to the benefit of the customer, which in reality tends to be the whole reason you are coding anyway (in the broad scope of things).

I'm getting plenty of practice with pitching what I'm doing to different levels. My mum often asks what I'm doing, and I have to explain in quite low level terms. My girlfriend asks, and I get to elaborate a bit more (only because she has more patience) but still have to be careful.

Jeff: I wonder if you can fix this blog annoyance? When I read Coding Horror, I tend to hit the first page, and then read through the entries. When I get to the bottom, I click on the "Read older entries" link at the bottom.

Unfortunately, that link doesn't take me to a page of your older entries, instead it takes me to a specific entry. I can't easily navigate through your posts in reverse chronological order, as much as I would like to.

Would you please fix this?

@Rob

Sorry, but I agree with Jeff - even though I work on data processing apps deep in the heart of very large companies, the most sucessful projects are those where we have a clear connection and regular contact with the end user. The hardest ones are where the developers are insulated by layers of architects, designers and business people who will not actaully use the data we produce.

> let go of the wheel and just do what the designer says

Wouldn't you also want to understand why the designer says to do something?

> The addicts talk mentions 50% of software developers as addicts.

What he's referring to is the 15 minute video linked at the bottom of the post. All the good stuff is in the first 10 minutes:
http://video.google.com/videoplay?docid=-317659265568822821

> many--probably most--developers have no need to explain their work to a layperson

Really? So the auto mechanic doesn't need to explain to the driver what's wrong with their vehicle, and why it will cost $1000? And the doctor doesn't need to explain to the patient why they need surgery, or medicine, or lifestyle changes?

> There is nothing strange about the conversation you quote

The last answer should have been the *first* answer-- eg, I'm fixing the datagrid sort order, because it's confusing our users. Get your mind right. Frame your work in terms of benefit to the customer/user. You build a house intending for people to live in it; similarly, you build software intending for people to use it.

> limited to the very narrow world of consumer product design.

Everyone has users. Everyone has customers. The difference between successful and unsuccessful software is that the teams who are successful frame all their work in the context of service to their audience. Without an audience, what's the point?

> However the best of teams also have people devoted to the technology

The best technologists tend to be the best communicators, people in tune with the overall product vision -- they don't just quietly squirrel away on technology in a lab, they'll happily tell you *why* that technology they're working on will let the users kick ass. That's part of the vision statement-- and it's something every developer should be able to do.

good post

I remember once complaining about co-workers not focusing on the software product our company was depending on. But then a friend of mine said; "do you put yourself in their place? Do you look at what the sales, economic or hr guy is doing? "

It is so easy to just sit on your chair, writing your silly code and complain about everyone not understanding what you are doing. I remember working at places where people would not put new paper in the printer because it was not their job, administrators would not help with the server because it was not their responsibility, and so on..

Communication is very important.
http://www.linuxkungfu.org/images/fun/geek/project.jpg
(old, but very good and so very true)

Almost everybody wants to show how great they are, maybe they want to show that greatness in their code or in the salary, but why not show their greatness in being the one that makes the solution a success. Be the one that connect the dots and makes coming to work a joy.

Saying that a programmer's job is not to write code is disingenuous. It's like saying that a construction worker's job is not to build a house, but to make sure that the customer has a warm place to sleep. This is wrong. The decision has already been made. The worker WAS hired to build a house.

As usual, Jeff, your opinions reflect the environment you work in, and the type of software you make. I refer you to Joel's "Five Kinds of Software".
Not all software has users in the normal sense of the word. Many programs are not desktop or web applications. Who is the user of a router's software? A car's computer? An automatic fruit sorting machine's software? Who are the users of a bank's HUGE software base? The customers? The tellers? Maybe OTHER pieces of software are the users?
Much of the software in the world does not interact with people at all. And when it does, those people have almost no control over it, no more than they can control the airplane they are traveling on (and even the pilots only have SOME control over an aircraft's software).

It is quite common for many programmers to be unable to easily explain what they are doing, since their job is the guts of software, and they work with abstract ideas. This is especially true if you work in the kind of software place where the software is extremely complicated, requiring dozens of programmers and many layers of abstraction.
It is also common in places where the person buying the product doesn't really know or care there's software inside (like a router).

"Customer: What are you working on?
Programmer: I'm building a lock-free linked list implementation".
"Customer: Huh!? what does that even mean? I'm paying you to build me a request processing server"
...10 to 20 minutes of explanations later (assuming the programmer is REALLY REALLY good at explaining complex, abstract ideas to laypeople):
"Customer: So how will that even help me?"
"Programmer: Your server will be able to function well enough when the expected 1000 people will work on it".

This is of course an imaginary conversation. Not one customer in 50 will agree to be subjected to such a complex explanation. Nor should they.
I don't care WHY my auto mechanic needs to replace the flux capacitor coils. Tell me what was wrong with the car, and if it's complicated, it doesn't matter. Just make it work, and tell me how much it costs (this assumes I trust my auto mechanic, but in the world of software, we generally do trust the programmers).
This is also why customers and programmers are sometimes separated, and communicate through special channels (like analysts, requirements, a customer's representative, etc...).

I do agree that it's very important for developers to know WHAT they are working on, and why, and all that jazz. I just don't think it's that important for those reasons.

Finally, the BEST technologies are sometimes excellent communicators, but not all of us are Peter Norvig. Many amazingly excellent technologists and developers are in fact quite poor communicators (at least to non-technical people). However, since they make software and generally need to communicate to technical people, that's not a real problem.

i have to mostly disagree. i think that the developer should be rock-solid in touch with customer needs, but i certainly don't think that he should need or want to be able to answer questions at a moment's
notice to satisfy a coworker in, say, marketing. that just exacerbates the reality that the technologists are being told what to do by the non-technologists.

it's more of a management issue -- the guys changing the ball bearings out on an airplane wheel shouldn't need to have clean hands and a cheery smile when the president of the airline drops by to ask about how much they love customer service. they should simply be the best damn ball-bearing replacement guys in the world. and the guy who is *their* boss should be busy sucking up to *his* boss to save them the agony of having to do so. that's why management jobs suck so much, and why there will always be jobs "in the trenches".

one sentiment as expressed i agree with, and that's that everyone should keep customer needs in mind. but it is certainly a marketing/sales mentality to pretend that design-the-box exercises have anything at all to do with whether or not the sorted list *actually gets fixed*. anyone can design a box, even if only semi-poorly. not anyone can fix the sort. don't require the guys who know how to fix the sort to learn to smile if the guys who know how to smile can't learn how to fix the sort.

nobody likes to hear, "be more like me because i can't be more like you."

s.

Hey Now Jeff,
This is a great post, I like the answer it's on the bug list. You are so right our job is not to write code, it's to provide solutions.
Coding Horror Fan,
Catto

@M
I think you missed the point. First off he said software developers, not programmers. To me a programmer is Joey Undergrad, fresh from the Uni. with his BS in one hand and a keyboard in the other. We were all "programmers" at one time or another, I know. But if we are any good at our profession we slowly become proactive in development and graduate to become developers.

Secondly, the comment on how we don't all need to be great communicators to be effective programmers. You're absolutely right. But at some point someone has to communicate with a user. To me Jeff's articles seem geared more towards professional growth. Yeah, I could fort-up in my cube churning out assembly optimized code all day or I could hire someone else to do that and I could go deal with customers so that we have money to allow people to code. That makes me a better developer and my resale value in the industry goes up.

Wow, I usually get 900k down off my work connection, the groktalk video is coming in a solid 8.5k and getting slower every minute. Some aspiring entrepreneur could start HorrorMirror.com

Keep up the good work!

@M
I think you missed the point. First off he said software developers, not programmers. To me a programmer is Joey Undergrad, fresh from the Uni. with his BS in one hand and a keyboard in the other. We were all "programmers" at one time or another, I know. But if we are any good at our profession we slowly become proactive in development and graduate to become developers.

Secondly, the comment on how we don't all need to be great communicators to be effective programmers. You're absolutely right. But at some point someone has to communicate with a user. To me Jeff's articles seem geared more towards professional growth. Yeah, I could fort-up in my cube churning out assembly optimized code all day or I could hire someone else to do that and I could go deal with customers so that we have money to allow people to code. That makes me a better developer and my resale value in the industry goes up.

Great article. I'm going to really start writing vision statements from now on. I'll admit, I'd neglected them...

Bob is an example of sooo many things that could go wrong in the design of a product, but it really came down to stupid arrogance -- MS devs and management thinking they knew better than their clients, and that's why we mock MS so for releasing this product. Their vision statement may have gone something like this:

for BEGINNING COMPUTER USERS
who WANT TO BE PRODUCTIVE ON THEIR COMPUTERS
the MS BOB PRODUCT is a ALL-IN-ONE SUITE
that MAKES IT EASIER TO USE YOUR MACHINE
unlike WINDOWS EXPLORER AND OFFICE
our product HAS AN ANIMATED DOG

I wrote about this sort of thing a while back and coined it the journalism model (TRADEMARK!!!!!).
If your developers can't explain the who/what/when/why/where of what they're developing, I see it as a management problem. My understanding of the problem set that I'm working to solve doesn't come from the ether.
I can give a better elevator-level description of what I'm doing and why when I've been involved in the project from its inception than when I've had a requirements document the size of a telephone book dropped in my lap.
You can't always have all your developers from start to finish, and that's where managers hypothetically come in - they keep a mental model of what needs to be done and keep people on track and excited about what they're doing (given all that yes I said hypothetically). I don't have much confidence that, were I to turn the tables, some managers would be able to pass the elevator test I posed to them either.
http://48klocs.blogspot.com/2007/07/software-development-journalism-model.html

A very famous philospoher, mathemetician, inventor once said:
"Please excuse the length of this letter, I did not have the time to make it short."

Those words are attributed to Blaise Pascal. What he was getting at is the crux of this blog post... If you can't explain something in a quick conversation, email, letter, etc... you don't have a deep understanding of what you are doing.

For the past 12 years, I have been a software developer in a variety of industries from car insurance, fiber optic management, retail market research, and even crop insurance data mining. At each of the places I have worked, I have generally spent 3-4 weeks up front just learning what the company did and why. That allowed me to frame my development efforts around what we are calling a vision... but in the broader sense of the organization, not just the application.

In all things, I try to work so that any explanation about the software (or the organization) would be such that a 9 year old could get the idea... Now that I work for the government, I have lowered that expectation to 6 year old!

The conversation at the top of this page is the process of breaking a developer's train of thought while they are getting useful work done.

I think the disconnect that some of the posters here have with Jeff's article is that the customer can be technical and have no problem with technical jargon. For instance, the customer of router software is the router manufacturer (the one paying for the work), not necessarily the end-user. I'm sure that Cisco is completely invested and interested in every aspect of the code that is programmed for them.

I think is some cases the "customer" of a piece of code is the project manager. If a PM breaks down a coding problem into a set of abstract parts and farms them out to set of developers, it may not be realistic for each developer to be able to explain how their individual piece will serve the customer.

That said, no developer works in a vacuum and must be able to accept direction and give feedback to the results of their coding. They must be able to interact with the customer, be it a PM, a tech manufacturer, or a layman end-user in a way that they understand.

You didn't mention a whole 'nother layer of disconnect.

The end user of the websites I work on is not my client - my client is the person hosting the site. As an experienced web developer who has studied web UI over the years, I often know better what will work for end users than the customer for whom I'm writing the software.

The only times either the client or the developers see a real live end user, is (maybe) when the site is for the client's internal consumption, or if we can convince them to invest in UAT (ROTFL)

sldr on September 27, 2007 07:08 AM:
The conversation at the top of this page is the process of breaking a developer's train of thought while they are getting useful work done.

That's funny - but maybe that's why it's supposed to take place in the elevator and not a cubicle. Perhaps it should be the parking lot test.

I love it! The "elevator test" is one of the first items that go into the Operational Concept Description documents I write for projects here. It helped in SO many ways when I had to rewrite a program due to bad programming and business logic in the current model. Using that elevator speech easily lines up the flaws and the benefits, which makes the "big wigs" more agreeable with the process.

I think I'm going to put an "elevator description" of a hobby program I have on the front page of the website and see if any saavy folks pick up on it. It makes for a great opening paragraph and intrigues people to click into the fine details.

Perhaps you missed the point? For me it is not so much what my job is but what my passion is, the last thing on my passionate list is usually what the clients business is involved with as its usually so boring I want to kill myself. My passion is programming, I focus on this point to the extent that in some instances it may blind my alternate thinking reality into a zone where the business problem is slightly faded, this however is not a bad thing as long as I bring it back into focus when needed. This lets us developers focus on the problem at hand, at least this is how I handle the situation.

Also soft skills are something you are really talking about here and lots of developers that the skills to communicate efficiently to the client the answers that are required. Given enough training/time this problem is usually resolved, however if you are a short term contractor the time duration is usually so short that the problem can only be resolved by proper training in how to interact appropriately with your client. With that kept in mind, not all situations will be kosher, if I am concentrating on something the client should avoid bugging me while this is in essence part of my reality distortion field where reality is bent into a particular pattern that is no recognizable by anyone other than myself I still wish for this particular interaction cooperation.

Just my $1.02, out!

It's amazing how many people here are missing the point. All the examples I've seen have simple, easy explanations:

Ball bearings? So the plane's wheels don't freeze up and cause the plane to crash. Car software: better gas mileage so the owner pays less, or better emissions so we all breathe better. Or maybe it's so that it just works better and causes the car fewer problems meaning less maintenance. Caching DNS server? Why would you put that in if not to reduce latency when the user is connecting to sites or to reduce your bandwidth bills so the company saves money? Router software: basically boils down to the router does what it's supposed to do better, so the users of the network have fewer problems.

If you can't boil it down to that level, as a developer you're in danger of doing something wrong, of going the wrong direction, of wasting your time and the company's money by doing the wrong thing. If you don't understand the impact that your work has to the bottom line, you may overwork something that's really trivial or underwork something that's essential.

And honestly, if you don't understand how your work affects things, do you know why they've hired you? Can you expect to keep your job?

I love the Design-the-Box idea. I wonder if anyone has taken that idea to the point of printing actual boxes for the team. For UI design, it seems popular to create and print elaborate personas to reflect typical users. One could do the same with the Box to clarify the software vision.

Great post. I think that programmers should also think about how they can help their customers fend for themselves. Things like encoding business logic in business rules and isolating highly volatile decision-making logic in their own decision services can make a huge difference.
JT
http://www.edmblog.com/weblog/2006/08/the_secret_of_b.html
http://www.ebizq.net/topics/biz_opt/features/6387.html

"The last answer should have been the *first* answer-- eg, I'm fixing the datagrid sort order, because it's confusing our users. Get your mind right. Frame your work in terms of benefit to the customer/user. You build a house intending for people to live in it; similarly, you build software intending for people to use it."

Jeff go find a construction site and ask the first guy you see why he's doing what he is doing. Chances are you wont get "Well the customer wants blah blah".

If someone came into my office and asked why i was doing what i was doing i was doing... i will tell them exactly why i am doing what i am doing in full on techno speak.

Why?

I make the assumption that anyone asking me questions in my office is there for technical reasons.

If not then why are they even in my office? They should be talking to the PM or the User liaison or they guy that wrote the User story. And why cant they read the User Story note card on my bulletin board? If they have a question on the technical decisions I am making then I'd gladly converse with them.

I also make the assumptions that those other people on my team are doing their jobs.

Like anyone at all in the business sphere gives 2 cents about what a programmer is doing or the decisions they make from a technical perspective.

What is my answer to that question when refactoring?

What are you working on?
I'm refactoring this bit of code.

Why are you working on that?
Because it lacks cohesion and has a cyclomatic complexity over 20.

Oh... Is it on the bug list?
No. But it needs to be reworked.

Why are you rewriting code? We need to have a meeting.
...

"A very famous philospoher, mathemetician, inventor once said:
"Please excuse the length of this letter, I did not have the time to make it short."

Those words are attributed to Blaise Pascal. What he was getting at is the crux of this blog post... If you can't explain something in a quick conversation, email, letter, etc... you don't have a deep understanding of what you are doing."

You sure its not because it is harder to explain things tersely and with brevity then not?

> i certainly don't think that he should need or want to be able to answer questions at a moment's notice to satisfy a coworker in, say, marketing

That's fair, but forget the customer for a minute. I've worked with plenty of developers who couldn't adrequately explain to *me*, one of their technical peers, what they were working on and why it mattered.

This isn't specific to commercial, consumer software. There are plenty of software products targeted at technical folks, even other software developers. The same advice still applies: you're building software to satisfy the audience in some way, so why not frame your work in that context?

> What is my answer to that question when refactoring?

I'm making it easier for us to make changes in our software later, and reducing the chance that those future changes will cause new bugs.

> You sure its not because it is harder to explain things tersely and with brevity then not?

It IS hard! You're absolutely right!

That's why the project should have a VISION STATEMENT which makes it dead easy for people to deliver a succinct, compelling summary of what the project is, and why their work on it matters.

"Get your mind right. Frame your work in terms of benefit to the customer/user."

You forget the situations where the answer is because we chose to do something using technology X. There are times when I have more work to do simply because we chose X, or moved to X after choosing Y.

When the answer is "because the boss said so" it may be time to move on.

Separation of duties is different per company. In some companies the developers will also be the project managers and decision makers. In others they have the developers do what they are told, period. The PM's decide the business reasons for why things are the way they are.

The answer "because the user said to do it that way" is the truth and it is the only reason the developer is doing it that way. If it were up the developer they would have done it a different way (and they did or else they wouldn't have received a change request).

Example: The business can decide to go down a path of reduced performance in order to gain added security or flexibility. It is not the developer's job to put their foot down and say no. It is their job to do what they are told and if the business later comes back and says they want performance instead then the developer can implement that. IT Managers can put their foot down, but developers do what they are told. Period.

The point you make with this entry is very similar to one I make quite often, and one I call the "Tool Test". All software is supposed to be a tool. It should allow a user to do at least one of the following:
1. Do a task faster.
2. Do a task easier.
3. Do a task better (with less mistakes)

If the end result of a software project will not do at least one of those things, it is a total waste of time and money, and should not be undertaken, or if already underway, scrubbed.

Too often we forget the elusively-simple fact that software is supposed to help in some way.

At a very basic level, I try to break down my operations into one of a few categories:

Scalability
Maintainability
Efficiency
Usability
Reliability

When I'm setting up the elevator talk or tracking my progress in general, I like to categorize things in one or more of these areas (I'm probably missing one or two as well). So my conversation can flow like this:

Why are you fixing the sort order on the datagrid?
-- To make it easier for the user to view their data. They've been having issues with it up to this point. Fixing the sort order also saves them a bit more time processing the record they need.

Why are you doing that fancy mumbo jumbo to the router?
-- So that it functions more efficiently and will adequately handle the 1000 concurrent users you're expecting next month.

"Example: The business can decide to go down a path of reduced performance in order to gain added security or flexibility. It is not the developer's job to put their foot down and say no. It is their job to do what they are told and if the business later comes back and says they want performance instead then the developer can implement that. IT Managers can put their foot down, but developers do what they are told. Period." -Kim

Unless that manager has the integrity to tell the business users that they now have to write the whole system again from the ground up, I am sure glad I don't work there.

The business MUST be made aware of the trade offs they are making, the cost associated with their decisions. From your post I doubt that they have even a clue, and that the IT Manager just goes along with whatever they say, including an impossible "deadline", which is why I don't work there. I doubt many good developers do either.

> Software developers think their job is writing code. But it's not.*
> Their job is to solve the customer's problem. Sure, our preferred
> medium for solving problems is software, and that does involve writing
> code. But let's keep this squarely in context: writing code is
> something you have to do to deliver a solution. It is not an end in
> and of itself.

The job is to implement the specifications as deliver by the sogftware designer, who created those specification from requirements gathered by the analyst.

It is the Business Analyst's and System Designer's jobs to turn the customer's problem in to something for the software developer to code.

If I'm told to code a sorted list, I code "sort(myList)" and I'm done.
You know the old metric about 10 debugged lines of code per day. This is debugged code. When I'm one-tenth done for the day.

What? You wanted the list sorted numerically? The specs said "sorted list", not "numerically sorted list".

Think I should know better? You're wrong. My job is to implement the spec. The spec that the analyst and designer got paid a lot of money to come up with.

Did we even have a QA session on the specs? Probably not. They tend to come from the ivory tower, and assumed to be correct. Only software get QAed. If you're lucky.

</rant>

Maybe we should put it another way. If you're a developer who wants to sit back and mindlessly code the requirements, you're expendable. Your job is one that can easily and effectively be outsourced to another company, offshored to India, China, Singapore, Eastern Europe, or whatever. New programming tools or methodologies will gradually make you less useful, because something will eventually let the business sort a list.

You offer no value. You will only be able to operate in companies with very static markets. You will not be able to capture opportunities in a rapidly changing business environment. Your company will eventually be bought or driven out of business by a more agile one, and you'll be out of a job.

My job is most certainly not to solve customer's problems. Why? Because customers are idiots. One step removed from a customer is a tester, who knows just enough of what they're talking about to be a tremendous pain in the ass on top of being an idiot.

My job is to take a problem and solve it. It's up to product/project/program management to define that problem if it originates from an outside source (and I'm including testers in 'outside').

It's bad enough that upper management will make promises to people that are not easily kept by the people that have to implement them. It's worse then when you think that it's my responsibility to have anything to do with the customer.

Jeff - I like your writing style, and tend to agree with your ideas most of the time. This is not one of those times.

What happens when you work in a large corporate structure and your project is not a customer facing one. Rather, your project involves building/maintaining a data repository, managing requests of some sort or another, providing web service access to some piece of data or another, etc. Now, your customers are other products within your company. You, as the developer, will know that you need to build a new method that will take in x and y, and then using those build a custom formatted return of v and w, sending an audit/billing record to z. You have no knowledge of what v and w are going to be used for or why they are needed, where x and y came from, or what z plans to charge if anything. Not only that, but you have no reason to know either.

Developers in my group can and will give you such answers to your why questions as "it was on my list of requirements for group X". If they didn't, nothing would ever get done.

I think you are confusing a developer in a small shop to a developer anywhere when you make your assumptions about what someone should and should not know.

What are you working on?
I'm fixing the sort order on this datagrid. (ok go away now, i am using the subtle body language cue of staring at an ide and typing, to indicate that i am concentrating)

Why are you working on that?
Because it's on the bug list. (oh no, here we go.. did your boss ask you to write him a status report? i'm working on it because it was assigned to me by you, our bug tracking system has been taking care of this stuff efficiently for months)

Why is it on the bug list?
Because one of the testers reported it as a bug. (wtf management by walking around? someone kicked you out of your office to use as a meeting room again? we showed you the button to click to get status reports from the bug reporting system, go play with your powerpoint, then i can close this one and make both of our stats look better)

Why was it reported as a bug?
The tester thinks this field should sort in numeric order instead of alphanumeric order. (that's what it says here in the bug reporting system)

Why does the tester think that?
Evidently the users are having trouble finding things when item 2 is sorted under item 19. (it's 3pm on friday and i want to finish up, it is worrying that you don't understand enough about this project to know why sorting data in the wrong order on this screen would be bad. i am trying to stay polite but my adrenal system is worn out from taking it from all sides. if you are implying that i screwed up, please just say so instead of putting me through the wringer, because I'll admit it straight off. or was that a trick question?)

Excellent post, Jeff! I recently got a new job and will be inheriting some young coders. I have printed off several copies of this and intend to hand it out when I start working.

Maybe someday when we are all “professional software engineers” we can live up to one tenet of the Code of Ethics for professional engineers that states:

“8) present clearly to employers and clients the possible consequences if professional decisions or judgments are overruled or disregarded”

http://softwareindustrialization.com/PreparingTheWorldForSoftwareEngineeringPart2.aspx

The answer to the question depends upon who asked it.

Technically minded folks might want to know about the details in the weeds.
Status report filers might want to know what they can put on the report.
End users might want to know if the reconcile checkbook feature is working yet.

If I'm working on the 'reconcile checkbook' feature, and I'm about 1/2 done with it and I'm working on some DataGrid or creating a user control, I ought to be able to figure out which answer is appropriate for the audience.

Doesn't seem like rocket science to me, but evidently it is.

I have a few problems with this.

First, abstraction is the key to developing software. It may well be good to know what business purpose the method you are debugging fills, but when you are down in the trenches working in the code, you can't be thinking about all that. All you need to be thinking about is "I am getting input x, I am supposed to return value y, but instead I'm returning value z". If instead you are too busy thinking about what high level function the user is trying to perform, you are never going to get the job done.

Second, as mentioned several times, a lot of software doesn't face customers at all. What if you are developing a framework that is being used by other developers? You don't need to know what business purpose the user of your framework is filling, your work should should be independent of that. In fact, if you are too focused on how a particular developer is using your code, that can lead to make it too specific to that particular purpose and not reusable for other developers.

Third, many changes that are made have no impact at all on the customer. For instance updating outdated or missing comments, fixing the code to match general coding conventions, and in general cleaning up code.

And fourth, if you think the project manager/architect/whoever wrote the high level designs did a bad job and you don't think a customer will ever use what you are told to design, you can't just throw away your assignment and work on something else. That will just lead you to losing your job. And its perfectly possible that your project manager is not the idiot you think he is and simply knows more about the business than you.

Jeff,

Not all of us develop products for customers to use. Some time we sell a product to OEM customers, who then sell it other OEMs, and etc before it gets to a customer.

So we're severely removed from the customer. And I hate that, because you end up designing software for "some customer" who might need feature A,B,C,D,E,F,G. When in reality, all the customer needed were features A, C, and G.

Kashif

If your life is just "code the spec" and you have no feel for why, or what good this can possibly do, you have a sad, shallow existence, and I pity you.

You also run the very real risk of doing the wrong thing. You need to understand how the software will be used, and by whom. If you do not, you will never know when to question the spec. If all I wanted was to turn a spec into code, I'd get a CASE tool.

We as humans have the capacity for so much more. We can notice when someone upstream who wrote the spec made an error (I have other people check my code, why not use this as a chance to check the spec.) We can maybe even see when the spec, while doing what they need, could be so much better for less work.

All software has users, whether internal, external, or just other developers. Every change affects them, even just fixing comments affects the speed and accuracy of future fixes.

Software without a user is pointless. I will not live that way.

As some people have said, amongst the mass of "we don't all write for customers", you can replace customer with any end user of the product (Surely you have one. If not, why the hell are you writing it?) If you don't know how you are writing is benifiting them then more than likely what you are writing isn't benfititing them.

Are people really living in a bubble of "spec in, code out" without any context what so ever? You don't even know who is going to use the code, where it is going to be used or how? That's just scary.
It seems most of you people need to learn how to stop taking things so literaly and be able to apply them to wider situations.

Wow. I work with tons of software developers, and not a single one would ever answer "because it's on the bug list." We all know why we're doing our tasks, even if we think the reason is stupid ("the users want a non-linear way to get to this option, but once I implement they'll see that it's really impractical to go another way").

For me, giving responses like those you started the post with would be an immediate red flag that this employee is not going to be very useful much longer.

Completely agree with Chris above. The conversation only happens with a slow learner. The very first thing a programmer who was given a bug would do is to verify the legitimacy of the bug. So the answer of sorting by numeric order should come quickly.

I love working with software (and hardware) engineers because of the concrete, inward looking, utterly absorbing, many-layered work they do. With an artificial language built on top of an extremely limited instruction set, they create something that can talk to a machine and make things happen.

That’s it: that’s the transaction at the heart of writing code.

To do this at a very high level requires a kind of attention, concentration, and devotion that is practically religious in nature. It’s not uncommon to see a certain species of engineer lose the ability to speak coherently after a few hours of writing code.

This is not “project management mind” nor is it “why-are-we-doing-this mind”. It is a state of rapt attention and intention more aptly compared to the spiritual or aesthetic mind found in prayer, meditation, art, or sport. To characterize this as a primitive state of mind is not to say it’s simple or unsophisticated, as Gary Snyder points out in his great essay “Poetry and the Primitive”, but to say it’s been with us from the beginning.

The primitive mind and its attendant joy in naming and making can of course be domesticated or cultivated for economic gain (Levi-Strauss, via Snyder) as surely as wild pigs or prairie. This is exactly what most of us are doing, as we sit in our cubes or offices amidst the great expanse of our multinational corporations or the more scaled down hillsides and vallies of smaller companies and startups.

Within these organizations, there are still thickets where the wild mind survives, and even thrives, and software engineering is one of those great preserves. Bill Gates’ (possibly only) genius is that he understood how to attract that kind of mind, then tame it to the end of making money.

When a human being writes a poem, makes a song, or tries to tame the wild machine, (s)he partakes in a primitive wonder that knows no remuneration (often quite literally). Oddly, it is this same human being an organization turns to with its most intransigent technical issues. No matter how erudite, facile at abstraction, or managerially converted we become, there is still a side of us that knows the real work of making. Yes, there are still worlds where no explanation is required.

As so many of you have pointed out, we don't always write software for a customer; however, I think you missed the point Jeff was trying to make. There is (almost always) a reason that we write software, someone who is the intended user, and some kind of capability that it provides.

I would argue that if you can't tell me the who/what/why of your software, you're not very good at what you do. If your first response is not at the highest level, that's fine. What's really important is that you actually know all of the subsequent (higer-level) answers.

If you don't understand what you're working on or why you're working on it at all levels of detail, you're probably not equipped well enough to do any of the following: reuse code that does something similar; write code that can be reused in the future; improve upon the prescribed solution; communicate or collaborate with your team or the business; prioritize; keep from repeating your mistakes; and be proactive.

The bottom line is, if you don't know the answers to these questions, you're buried too deep in your current task to understand how you could be doing it better. This can easily become an endless cycle: you keep rushing to put out fires, and all that happens is you get burned by more fires. Take a step back, figure out what you're doing, communicate with people around you, and find a better way to work.

I couldn’t agree more! What makes matters worse is not only are they unaware, they also believe that understanding business requirements is a WASTE of their time. They would rather spend 5 days finding the fastest way to sort a grid than spend 5 minutes understanding why the end user needs a sort in the first place.

People who disagree with you have been lucky to not experience such developers first hand; else they would empathize.

But is having a vision statement enough?

Preeti Edul

If you can explain WHY you are writing code, share it also with me and I'd understand myself a little better. I don't see any reason why I'm banging a plastic box 10+ hours a day when I could make my living in some other more humane way. Still, it's the only job I'd ever really want to do. If someone asks me to write a piece of code that sorts a list, I don't give a fuck what it is used for, all I care is writing a masterpiece of code. Prefer bogosort.

btw. go ask a mathematician or physicist what their latest results can be used for.

What gives you the authority to pontificate on the subject of software development? Your rabble wisdom speaks only to serfs, yet you speak of "Software Development" as if you were a god passing judgement on the entire industry. How enfuriating! I wouldn't have read this at all if my boss hadn't "enlightened me" with this heaping pile of horse crap. Now, what about code reuse? What if you are creating tools for other software developers? It amazes me how much you fools can get away with. You are like that guy Dr. Phil who "cares so much" about these morons living in trailer parks and these "middle class super rabble" that are even worse. You are trying to appeal to something, something. Got it. Your attempt is to simultaneously add credibility through a false sense of security while hinting that personal growth is in order. You do this instead of saying "YOu are worthless and I will destroy you!". That is too scary. Perhaps, you are afraid of this yourself. Perhaps your musings are an unconcious attempt to give yourself credibility. Who knows? Who cares? It doesn't matter. However when someone is this transparent, it is usally a cry for help. So, here is my advice: STFU!

hmmmm... Have you ever worked with Chinese or Indian software companies? - they certainly subscribe to the Idea of:

"Software developers think their job is writing code."

An Analyst formulates requirements, the developer takes the requirements and "codes" them (amongst other things, such as unit test, document, version control etc), and the PM oversees that requirements (and eventual solution) will meet the expectations of the business.

In some businesses there is never any direct contact to a "Developer" - as a analyst (business/solutions) has the ability to properly explain functionality to the end user - as this requires skill's that a developer is not necessarily expected to have.

You don't ask a painter to cook you a cake (unless of course they're a cook as well).

In my world, my team aren't interested in "why does the business I work for sell widgets", and I don't think they should be. Its not their job to get excited about that. They are (or should be!) interested in "the page that allows the business to sell a widget will be 5x more productive if I implement <xyz> - and this is the cool way I would do it..."

Steve

brian:
the Pascal comment was meant to illustrate that most people will ramble on about something and continue to fling BS at you trying to show you they "know" what they are talking about... but if you can't explain what you are talking about (or doing) in very basic terms, you may not have a deep understanding of the subject matter.

I can say in my experience that the times I've had the most success at any project was when I knew the why's and what's of what I was programming not just the how.

I have had several programmers working for me over the past 2 years that were "spec in, code out" types. And as the lead, it was a pain in the azz...
Case in point, the spec says: "the data will always contain a 4 digit number."
So one of my developers didn't check for Nulls or zero. I noticed this and asked him to handle those cases, his response was the spec didn't mention that. So, we take it to the person that wrote the spec (the BA for the data analyst), they confirmed "there will never be nulls in the data".

I was subsequently overruled, and the product went live. Within 3 hours, the data had nulls and the program started throwing errors.

I would much rather have had a programmer that went the extra step to find out how the dat would be populated and then add in null protection. Me pointing out that the column in the database was not set to NOT NULL, didn't seem to convince them that nulls could get in there.

I apologize for the length of this post...

Developers certainly need to see and know the Big Picture, but to the same extent that other members of the team need to know the Small Picture.
Coders <make> the software – they create the product. Marketers, salespeople, HR folks – these people are key members of the team, but most have no idea what the Small Picture is. None. It is as disingenuous to say “I don’t care if the software is written in …iguana juice” as it is to say “Because one of the testers reported it as a bug.”
Many developers would fail the elevator test, but many other members of the company would not be able to answer simple questions about the core construction of their products. Could they respond correctly to “What language is our product written in?” or even “What operating system does our product run on?” These things matter, and to imagine that a product written in, say, COBOL, is equivalent to one written in Java is silly. Maybe the one written in COBOL still solves the customer’s problem today, but I ain’t taking any stock options with that company.

At a quick glance through the comments (I only read the first 20 or so in detail... others I just skimmed) it seems a roughly 50/50 split between people who agree with Jeff on this and those that don't.

I'm with the "don't" group on this one. I can think of many valid reasons why an elevator conversion should go exactly like the one described. But regardless of that this article doesn't take into account who the customer is nor who the interrogator is.

I've been in some organizations where the only input a developer has is an email from their manager with a change request. This effectively makes the customer your manager and manager's are notorious for not wanting to explain themselves to their subordinates ("Dan, make this change before you go to lunch. Chop-chop.").

More importantly, when *I* am asked what I am working on in the elevator I tailor my answer to the person asking the question. If its an executive I would give them a response involving the customer and how we're keeping them happy. If its a technical person I'll give them a more technical answer. If its the receptionist I'll say "nothing important, wanna go to lunch?"

There was a time when this blog had entries on why our life is great because we can code 'this' to achieve 'that'. Now-a-days we have entries on why our lives are miserable exactly because we can code this to achieve that.

Maybe Jeff has climbed up the management ladder.Adieu friend, so long and thanks for all the fish!

All the idealism and pragmatism on this page is impressive. Let's add a medical thought: I suspect that some developers I've worked with had Aspergers Syndrome and were incapable of relating to other sentient beings. But man, were they really great heads-down developers (for which there is a need).

If you are still reading at this point, GET BACK TO WORK! :p

"I TAKE THE SPECS FROM THE CUSTOMERS TO THE ENGINEERS!!"

"Well why can't the engineers just take the specs directly from the customers?"

"BECAUSE ENGINEERS AREN'T GOOD WITH PEOPLE, EVERYONE KNOWS THAT!!"

All hale Office Space. Fortunately for me, I develop applications for use in-house, so if I don't solve the customer's problem then he/she will be standing on my desk within the hour. I think it's been a great learning experience for me in the difference between righting code for code's sake and writing code that solves customer problems. Perhaps all budding software developers should be force to directly interface with customers early on in their careers?

This post and the one on coding the "smallest" thing possible are nice, because discipline is good, but I personally put these arguments in the context of these two imperatives:

- Do you (the software engineer/designer/programmer) enjoy your job? Are you having fun?
- Does the customer like what they're getting, and do they like interacting with you?

Writing software, and consuming software, all happen in the realm of life, and the purpose of life is to be happy. Thinking about the process too much, and doing too much introspection, causes neuroses. They call it "coding bliss" because it's blissful. You shouldn't have to give that up.

It's all too easy to spot the code addicts in the comments. "Hey, I just want to code! It's somebody else's job to make sure it's relevant." Your privilege to feel that way, of course. But there are implications to that way of thinking, whether you like it or not.

Alan Shutko summed it up best in his comment above: "If you're a developer who wants to sit back and mindlessly code the requirements, you're expendable. Your job is one that can easily and effectively be outsourced to another company, offshored to India, China, Singapore, Eastern Europe, or whatever." The guys who focus on nothing but code may not like that, but it's the world we live in.

Yes, I also agree with Alan Shutko. Going that extra mile to understand all aspects of the company you work for may or may not be your job, but you can damn well bet that some day your job will depend on it. If you can't explain why what you do helps the company make money in the greater scheme of things, how can you conceivably justify your paycheck to your employer?

To use the auto mechanic analogy; would you choose the guy who simply works on your car doing only what you asked him to do, who then hands you a bill without explanation? Or would you go to the guy that takes the time to explain why you need to replace your worn out spark plugs and brake pads, even though you only came in for an oil change?

Words are just used to communicate.

Granted, from the same question, you can get different answers from the developer, depending on who is asking. I know I would answer differently to my boss(we are chasing the deadline so we can bill them early), my client(the problem you mentioned, yeah, I'm fixing it), my colleague(maybe if we can ship it earlier, we can get some bonus this year), and heck even my kid (dad is doing work). Are you expecting the same answer every time a developer was asked about what he is doing? Maybe you should reflect on what perspective the developer has when he was asking the question.

take the stairs ppl.

I agree with having a project vision statement. As the PM, it's my job to keep everyone focsued to make the best use of everyone's time and to get the product to the customer, on-spec, and on-time. Pointing to the vision statement (we call it the project objective statement, same thing) shuts down a lot of unnecessary chatter and the occasional folks who 'drive by' and decide the scope really has more to it. I really stress the value to the business and if folks are writing code or spending time on anything not contributing to the vision, then they are wasting their time and the clinet's money.

this is the classic staffing issue. Companies that dont hire project managers and business analysts are "playing house". Why is the analysts problem, how is the developer/architects problem. As software engineers it is our duty to create elegant mainatainable algorthims that solve the problem. If we are given system requirements and function specifications we can build software that is accurate to the business's need. Typically the types of people that make great software guys are not the same types of people that make great analysts.

I agree with the guy who called you a pontificating idiot.

When I go to the doctor, I don't expect the nurse taking my blood pressure to know the details of my condition.

When I get my car detailed, I don't expect the guy waxing my car to know or care about my date plans.

When I go to the deli and get a fruit salad, I don't expect the guy at the counter to know what kind of party I am throwing.

If the programmers are having to worry about the customer's needs, then the intermediate levels (pm, ba, architect, designer) have not done their job properly.