Softpanorama (slightly skeptical) Open Source Software Educational Society

May the source be with you, but remember the KISS principle ;-) Softpanorama Search

Programming as a Profession

A very interesting view about programmer as a profession can be found in Ershov paper: Andrey Erchov Aesthetics and the human factor in programming (CACM)

Slightly simplifying there are two contrasting ideologies of programming: Software Realism and Software Idealism. The latter in their turn can be subdivided into two major schools: Stallmanism and Raymondism. 

Here is how I defined them  in 1999 (the quote below is taken from Softpanorama OSS page):

In the vision of Software Realists programmers like all humans have weaknesses and guided primarily by self-interest and as such requiring formal organization and incentives (direct or indirect) to act outside the limits defined by their own self-interest. Software Realists see the evils of the software world as given and derived from the limited and unhappy choices available, given the inherent moral and intellectual limitations of human beings and existing hardware.   Some of them try to create better software like programmers involved in creation of all BSD flavors but they consider commercial programmers as equals (actually many of them wear two hats) and do not object to reusing the code that they developed pro bono in proprietary software. 

In this slightly tragic worldview the software development is a hard and often underappreciated labor that requires special, pretty rare, talent  People with this talent like talented sport stars (for example tennis players or ice ballet dancers) risk their health while they are young creating short living but tremendously complex artifacts (large software systems are probably the most complex system even created by humans) and for this reason should be remunerated accordingly.  It is important to understand that like in case of artists creating paintings on the sand beach programmers creation are short-lived and the new wave of hardware often wipes them clean.  For example, who now remembers the creators of PL/1 optimizing and debugging compilers, the compilers that were real breakthrough in many areas of complier writing art and in comparison with which some modern compliers still look like junk despite the fact that they were written 30 years ago.

In other words they see that due to immense complexity of those artifacts all software sucks. It is just that some software sucks less. It can be proprietary software, it can be free software -- all depends of the talent of the creators not so much on a particular ideology (which, by the way, can be completely wrong: Soviets invented quite a few new technologies and managed to launch the first man into space).  Thus, in view of Software Realists school the perfection of software is unachievable and old good Unix with its classic codebase might sometimes be preferable to new Turks be it Windows or Linux. That does not mean that Linux or Windows codebase is all crap. That just means that they are just another OSes in a long historical line of such systems. In some areas they might be better then competition, in some worse, but none has the monopoly on innovation (actually Linux is a pretty conservative kernel despite a radical ideology behind it). 

Software Realists are unconvinced by claims of linux superiority and want to see hard facts.  Furthermore, history guided them that the proper tradeoffs between different subsystems of OSes can be ironed out only via long, expensive and painful process that requires strong highly paid managers, programmers and testers who are ready to sacrifices their health for the success of their creation. The real art requires sacrifices and it is better when such sacrifices are properly remunerated, although stores of talented artists who died in poverty are nothing new. 

Because real talents are rare good software is a very expensive thing.  Software realism school  presuppose that modern software is almost always a compromise between the demands of the talent and demands of the marketplace.

The Software Idealist school (both in its Stallmanism and Raymondism incarnations) holds that mankind in general and programmers in particular has not yet achieved their full moral potential, and that they are (at least in principle) perfectible if guided by wonderful new software development ideology.  Foolish and immoral choices inherent in the creation of proprietary software explains the all the evils of the existing software world  and revolution was needed and actually already  came in the form of either free software movement or its less pure form called open source software movement. Both major Software Idealism schools rely on volunteer labor of programmers connected via Internet to produce immortal gems of software wisdom that will crush proprietary software developers like cockroaches. 

In Software Idealism  worldview, whether purely moral incentive actually work in a long run or not and what will happen when Linus Torvalds will become yet another retired dot-com multimillionaire with his own yacht is irrelevant to the achievement of true software justice, justice for all.  This utopian view holds that  volunteer programmer potential is immense and can do everything including improving human nature that should get rid of those outdated  economic rewards for software development and be satisfied  working part time in McDonalds in order to be able to participate in the movement. So the Software Idealism vision promotes pursuit of the highest ideals which somehow guarantee the best software solutions. At the end of the day new liberated men should all storm this evil Bastille of software oppression which is of course Microsoft and dance on its ruins. Sometimes in their enthusiasm  they can attack other sinful old fashioned proprietary software vendors instead of  Microsoft.  Until opening Solaris (and even after that) sometimes their target was Sun.

And if the unwashed masses who corrupt their soils by using Windows are slow in catching on, then it is the role of the intellectual vanguard (the keepers of programming craft who in Eastern Europe might be called "programming intelligentsia") to lead them  - even if in the short run, the masses can be unhappy with the results because they might not be able to use full capabilities of their laptops, cameras or scanners.  In general Software Idealists think that higher considerations should guide us and that those consideration somehow guarantee creation of a better software, the software that is not only better but which is as perfect as it is free.

Again this is a slight simplification but I believe it somehow catches the key points. 

Old News ;-)

[Feb 12, 2008] Inter-Sections » Blog Archive » How to recognise a good programmer by Daniel Tenner

This is good post of the pretty fuzzy theme and as such it should be taken with a grain of salt as there is no universal criteria and also programming like love is a very fuzzy word. For example early start is a good indication of abilities but that does not mean that somebody who has early start in other discipline cannot switch to programming and reach the top. Ability to write is another, but it is not as universal as one might think... Game programming is not the same as RPG programming of financial applications. IMHO comments are more interesting the post... Also compare with Aesthetics and the human factor in programming by Andrey Erchov

How do you recognise good programmers if you’re a business guy?

It’s not as easy as it sounds. CV experience is only of limited use here, because great programmers don’t always have the “official” experience to demonstrate that they’re great. In fact, a lot of that CV experience can be misleading. Yet there are a number of subtle cues that you can get, even from the CV, to figure out whether someone’s a great programmer.

I consider myself to be a pretty good programmer. At the same time, I’ve spent a fair amount of time on the business side of the fence, filtering technical CVs for projects, interviewing people, etc. Thanks to this, I think I have a bit of experience in recognising good programmers, and I want to share it in this article, in the hope that it may help other “business guys” to recognise good programmers. And, who knows, perhaps some programmers who have the potential to be good but haven’t really exploited this can also read this and realise what they need to do to become good (although, as I’ll argue, that’s definitely not accessible to all programmers!).

In his article The 18 mistakes that kill startups, Paul Graham makes the following point:

“… what killed most of the startups in the e-commerce business back in the 90s, it was bad programmers. A lot of those companies were started by business guys who thought the way startups worked was that you had some clever idea and then hired programmers to implement it. That’s actually much harder than it sounds—almost impossibly hard in fact—because business guys can’t tell which are the good programmers. They don’t even get a shot at the best ones, because no one really good wants a job implementing the vision of a business guy.

In practice what happens is that the business guys choose people they think are good programmers (it says here on his resume that he’s a Microsoft Certified Developer) but who aren’t. Then they’re mystified to find that their startup lumbers along like a World War II bomber while their competitors scream past like jet fighters. This kind of startup is in the same position as a big company, but without the advantages.

So how do you pick good programmers if you’re not a programmer? I don’t think there’s an answer. I was about to say you’d have to find a good programmer to help you hire people. But if you can’t recognize good programmers, how would you even do that?”

I disagree with Mr Graham on this one. I think there are a number of very strong indicators of a “good programmer” (and, conversely, strong indicators of a “not-so-good programmer”) that even a business guy can recognise. I’ll summarise some key indicators and counter-indicators in a list at the end of the article.

#1 : Passion

In my corporate experience, I met a kind of technical guy I’d never met before: the career programmer. This is a person who’s doing IT because they think it’s a good career. They don’t do any programming in their spare time. They’re shocked when they find out I have a LAN and 3 computers at home. They just do it at work. They don’t learn new stuff unless sent on a training program (or motivated by the need to get a job that requires that technology). They do “programming” as a day job. They don’t really want to talk about it outside of work. When they do, they talk with a distinctive lack of enthusiasm. Basically, they lack passion.

Gordon January 11th, 2008 at 10:07 pm I think the passion indicator is entirely overrated. I see cases all the time, especially in college, where a person’s passion exceeds their abilities. They are the same people who spend day and night in the computer labs and even know a plethora of cutting-edge technologies, but are ultimately mid-tier students who are passed up by truly good programmers. With that said, raw intelligence is the best indicator. That’s why puzzle questions are not entirely bad. They generate less false-positive, which is the worst-case for a new hire, and are harder to fake. All of the qualities you listed above can be faked easily. They are also universal in the sense that the business-minded variety are capable of asking them.

I believe that good developers are always passionate about programming. Good developers would do some programming even if they weren’t being paid for it. Good programmers will have a tendency to talk your ear off about some technical detail of what they’re working on (but while clearly believing, sincerely, that what they’re talking about is really worth talking about). Some people might see that as maladapted social skills (which it is), but if you want to recognise a good developer, this passion for what they’re doing at the expense of social smoothness is a very strong indicator. Can you get this guy to excitedly chat up a technology that he’s using, for a whole half hour, without losing steam? Then you might be onto a winner.

#2 : Self-teaching and love of learning

Programming is the ultimate moving target. Not a year goes by without some new technology robbing an old, established standard blind and changing half the development universe. This is not to say that all good programmers pick up these changes and ride the bleeding edge. However, there’s a class of programmers that will never, ever pick up a new technology unless forced to, because they don’t like learning new stuff. These programmers will typically have learnt programming at university, and expect to get by on whatever skills they picked up there, plus whatever courses their company is willing to send them on.

If you’re thinking of hiring someone as a programmer, and he ever utters the words “I can work with that, just send me on a training course for a week and I’ll be good at it”, don’t hire that guy. A good programmer doesn’t need a training course to learn a new technology. In fact, the great programmer will be the one talking your ear off about a new technology that you haven’t even heard of, explaining to you why you must use it in your business, even if none of your staff knows how to use it. Even if it’s a technology he doesn’t know how to use yet.

#3 : Intelligence

Some business people assume that lack of social tact and lack of intelligence are the same. Actually, intelligence has several facets, and emotional/social intelligence is only one of them. Good programmers aren’t dumb. Ever. In fact, good programmers are usually amongst the smartest people you know. Many of them will actually have pretty good social skills too. The cliché of the programmer who’s incapable of having a conversation is just that - a cliché. I’ve been to a few meetings of the London Ruby User Group and I can say that with only a very few exceptions, most people there are smart, talkative, sociable, have varied interests, etc. You wouldn’t look at them chattering away in the pub and think “what a bunch of geeks!” - at least until you approach a group and realise they’re talking about the best way to design a RESTful application with a heavy UI frontend.

This doesn’t mean that they’ll all feel comfortable in every social context. But it does mean that if the context is comfortable and non-threatening enough, you’ll be able to have as great a conversation with them as you would with the most “socially enabled” people (perhaps better, since most good programmers I know like their conversation to revolve around actually useful topics, rather than just inane banter).

Don’t ever hire a dumb person thinking they’re a good developer. They’re not. If you can’t have a great conversation with them in a relaxed social context, they’re very likely not a good programmer. On the other hand, anyone who’s clearly very smart at the very least has a strong potential to be a good or great programmer.

#4 : Hidden experience

This is correlated with the “Passion” point, but it is such a strong indicator that I’d like to emphasise it with its own point.

I started programming when I was about 9, on a Commodore 64. I then migrated onto the PC, did some Pascal. When I was 14 I wrote a raycasting engine in C and Assembler, spent a large amount of time playing with cool graphic effects that you could get your computer to do by messing directly with the video card. This was what I call my “coccoon stage”. When I entered that stage, I was a mediocre programmer, and lacked the confidence to do anything really complicated. When I finished it, I had gained that confidence. I knew that I could code pretty much anything so long as I put my mind to it.

Has that ever appeared on my CV? Nope.

I strongly believe that most good programmers will have a hidden iceberg or two like this that doesn’t appear on their CV or profile. Something they think isn’t really relevant, because it’s not “proper experience”, but which actually represents an awesome accomplishment. A good question to ask a potential “good programmer” in an interview would be “can you tell me about a personal project - even or especially one that’s completely irrelevant - that you did in your spare time, and that’s not on your CV?” If they can’t (unless their CV is 20 pages long), they’re probably not a good programmer. Even a programmer with an exhaustive CV will have some significant projects that are missing from there.

#5 : Variety of technologies

This one’s pretty simple. Because of the love of learning and toying with new technologies that comes with the package of being a “good programmer”, it’s inevitable that any “good programmer” over the age of 22 will be fluent in a dozen different technologies. They can’t help it. Learning a new technology is one of the most fun things a programmer with any passion can do. So they’ll do it all the time, and accumulate a portfolio of things they’ve “played around with”. They may not be experts at all of them, but all decent programmers will be fluent in a large inventory of unrelated technologies.

That “unrelated” bit is the subtle twist. Every half-decent java programmer will be able to list a set of technologies like “Java, J2EE, Ant, XML, SQL, Hibernate, Spring, Struts, EJB, Shell scripting”, etc.. But those are all part of the same technology stack, all directly related to each other. This is possibly hard to recognise for non-programmers, but it is possible to tell whether their technology stack is varied by talking to them about it, and asking them how the different technologies they know relate to each other. Over-specialisation in a single technology stack is an indicator of a not-so-good programmer.

David Emery January 11th, 2008 at 10:26 pm Good list and I’d like to emphasize #5. My position is that I -never- hire a programmer without experience/knowledge of more than 1 programming language. The Sapir-Whorf hypothesis applies; if you know only 1 programming language you can’t really think through alternate approaches to the problem. I’ve told people who clearly qualified based on the other criteria in this list, “Go learn another programming language and then come back and I’ll hire you.” See also this article: http://www.stsc.hill.af.mil/CrossTalk/2008/01/0801DewarSchonberg.html With respect to #4, some of us are old enough that our first chance to do any programming was when we got to universities. And that’s a point I’d like to make: Experience counts. Someone with 20 years experience, even if it’s not in the hottest technologies, but that otherwise meets these criteria, is often likely to be more productive in the middle to long run, than someone with 1-2 years of direct experience but no “time-in-life”. A tremendous amount of stuff I experienced 20 years or more ago in some “antique” technology is still relevant; part of the skill to look for is an ability to apply life experiences to the new technologies. Remember that 1 good programmer significantly outperforms several mediocre programmers (based on both skill and Brooks’ Law about team sizes.) dave

Finally, if some of those technologies are at the bleeding edge, that’s a good positive indicator. For instance, today (November 2007), knowledge of Merb, Flex, RSpec, HAML, UJS, and many others… Please note that these are fairly closely related technologies, so in a couple of years, someone who knows all these will be equivalent to someone familiar with the Java stack listed in the previous paragraph.

Update: As a clarification to this point, there’s in fact two indicators here: variety and bleeding edge. Those are separate indicators. A good variety of technologies across a period of time is a positive indicator, whether or not the technologies are bleeding edge. And bleeding edge technologies are a positive indicator, whether or not there’s a variety of them.

#6 : Formal qualifications

This is more a of non-indicator than a counter-indicator. The key point to outline here is that formal qualifications don’t mean squat when you’re trying to recognise a good programmer. Many good programmers will have a degree in Computer Science. Many won’t. Certifications, like MCSE or SCJP or the like, don’t mean anything either. These are designed to be accessible and desirable to all. The only thing they indicate is a certain level of knowledge of a technology. They’re safeguards that allow technology recruitment people in large corporations to know “ok, this guy knows java, he’s got a certification to prove it” without having to interview them.

If you’re hiring for a small business, or you need really smart developers for a crack team that will implement agile development in your enterprise, you should disregard most formal qualifications as noise. They really don’t tell you very much about whether the programmer is good. Similarly, disregard age. Some programmers are awesome at 18. Others are awesome at 40. You can’t base your decisions about programmer quality on age (though you might decide to hire people around a certain age to have a better fit in the company; please do note that age discrimination is illegal in most countries!).

As a final note to this, in my experience most average or poor programmers start programming at university, for their Computer Science course. Most good programmers started programming long before, and the degree was just a natural continuation of their hobby. If your potential programmer didn’t do any programming before university, and all his experience starts when she got her first job, she’s probably not a good programmer.

Disclaimer

None of the indicators above or below are sure-fire indicators. You will find great programmers who break some of those moulds. However, my view is, you’ll rarely find a great programmer that breaks all of them. Similarly, you may find poor programmers that meet (or appear to meet) some of these criteria. But I do strongly believe that the more of these criteria a programmer meets, the more likely they are to be one of those elusive “good programmers” that, as a business guy, you need to partner with.

Richard January 11th, 2008 at 10:28 pm As someone that has programmed for nearly 15 years (hobby and professionally) with a background in psychological research I hate to say I find this “essay” not very scientific. This is all based on anecdotal evidence, stereotypes, and conclusions were reached without a solid methodology. Can I find people that fit these bullet items that are good programmers? Sure, but I can also point to some really bad programmers that fit this model in nearly every way also.

The criteria in bullets

So, in summary, here are some indicators and counter-indicators that should help you recognise a good programmer.

Positive indicators:

• Passionate about technology
• Programs as a hobby
• Will talk your ear off on a technical subject if encouraged
• Significant (and often numerous) personal side-projects over the years
• Learns new technologies on his/her own
• Opinionated about which technologies are better for various usages
• Very uncomfortable about the idea of working with a technology he doesn’t believe to be “right”
• Clearly smart, can have great conversations on a variety of topics
• Started programming long before university/work
• Has some hidden “icebergs”, large personal projects under the CV radar
• Knowledge of a large variety of unrelated technologies (may not be on CV)

Negative indicators:

• Programming is a day job
• Don’t really want to “talk shop”, even when encouraged to
• Learns new technologies in company-sponsored courses
• Happy to work with whatever technology you’ve picked, “all technologies are good”
• Doesn’t seem too smart
• Started programming at university
• All programming experience is on the CV
• Focused mainly on one or two technology stacks (e.g. everything to do with developing a java application), with no experience outside of it

I hope these help. Let me know below if you have any comments, or anything to add to them!

Thanks for reading.

[Feb 11, 2008] What Makes a Good Programmer By Katherine Noyes

At a Loss for Words

Yet it is a heavy responsibility, too, which is why this week we'd like to direct our readers' attention to a recent post by Red Hat (NYSE: RHT)  blogger Havoc Pennington pointing out a very excellent article by blogger Daniel Tenner titled "How to recognize a good programmer."

While Pennington's post was from Tuesday, the article itself dates back to a blog post from November. Given the timeless importance of the article's topic, we wouldn't even point out its publication date were it not for the shocked reaction we got from certain Slashdot founders, who went only so far as to say, "My only comment is that you should try to be more punctual :)."

We can only assume the topic's profound importance and magnitude rendered those unnamed Slashdot founders at a loss for words.

Misleading Resumes

Other bloggers, fortunately, were much more forthcoming on the topic, which is so central to the daily lives of so many of us.

Tenner writes that good programmers are not always easy to recognize, particularly for those who are not programmers themselves.

"It's not as easy as it sounds," writes Tenner, who has worked both in programming and on the business side.

"CV experience is only of limited use here, because great programmers don't always have the 'official' experience to demonstrate that they're great. In fact, a lot of that CV experience can be misleading," he adds. "Yet there are a number of subtle cues that you can get, even from the CV, to figure out whether someone's a great programmer."

You're Good If...

Among Tenner's list of positive indicators suggesting someone is a good programmer are:

• Passionate about technology
• Programs as a hobby
• Will talk your ear off on a technical subject if encouraged
• Significant (and often numerous) personal side-projects over the years
• Learns new technologies on his/her own
• Opinionated about which technologies are better for various usages
• Very uncomfortable about the idea of working with a technology he doesn't believe to be "right"
• Clearly smart, can have great conversations on a variety of topics
• Started programming long before university/work
• Has some hidden "icebergs," large personal projects under the CV radar
• Knowledge of a large variety of unrelated technologies (may not be on CV)

Do these technologies describe you or someone you know? If so, you may be in the midst of greatness, according to Tenner.

Passion Is Key

"I don't consider myself a good programmer yet (but a TON of those things applied to me), and I have no experience in hiring programmers," Monochrome Mentality blogger Kevin Dean told LinuxInsider.

Passion, however, may in fact be one of the unsung heroes of the open source development model's success, Dean asserted.

"As a general statement, I've often disagreed with Eric S. Raymond and Linus Torvalds about the open source development model producing 'better' code," Dean said. "A topic not really discussed by either of those guys was the number of people passionate about the code they were writing."

Free software allows people to choose the projects that interest them, Dean added. "I've always thought this factor was the single MOST important reason for 'better code,' rather than 'more people looking at it,'" he said.

Nice Guys First

Traditional experience and certifications may be less indicative of programming skill than other characteristics, agreed Slashdot blogger yagu.

"There's a lot of conventional wisdom that good programmers come with exceptional brilliance, and lots of certifications proving their mastery (read 'certifications')," yagu told LinuxInsider. "While I'd expect a good programmer to be smart, I couldn't care one lick for their paper trail, short of ground-breaking doctorates awarded on research in the industry."

One trait characteristic of good programmers is friendliness, yagu asserted.

"Contrary to the classic, mysterious and cranky genius in a dark back room, a good programmer does have social skills and should be friendly and easy to communicate with," he said. "If you can't talk with a programmer, you'll never communicate needs efficiently. This is a cornerstone of creating useful software."

Along similar lines, good programmers are generous in spending time helping others use applications and understanding technology, yagu said, and they are empathetic. "He doesn't judge or criticize a user as 'stupid,' but tries to see their problem as they experience it and then works with the user to come up with a solution," yagu explained.

Mystery and arcane jargon are not things good programmers promote or hide behind, he added.

Did We Mention Passion?

Good programmers don't have to be geniuses, yagu added, but they should be smart and they should have a creative approach. "A good sign of smart would be a programmer who has mastered several, if not many, programming languages," he said.

Indeed, good programmers are well-rounded, yagu added. "Find me a programmer who also loves to bicycle, attend theater, read a good book," he said. "A programmer with external and various interests is going to look at the universe without the distortions of a 'technology-only' lens."

Finally, passion is another key characteristic of good programmers, yagu agreed. "A good programmer loves to describe the intricacies and nuances of technology, often beyond your need to know or capacity to understand," he said.

And on that timely note -- passion, that is -- we here at LinuxInsider would like to remind our readers that Valentine's Day rapidly approaches. Don't forget the human factors!

embracing-my-inner-geek-part-2-the-job

Compare with Aesthetics and the human factor in programming by Andrey Erchov

A software developer must be part writer and poet, part salesperson and public speaker, part artist and designer, and always equal parts logic and empathy. The process of developing software differs from organization to organization. Some are more "shoot from the hip" style, others, like my current employer are much more careful and deliberate. In my 8 years of experience I've worked for 4 different companies, each with their own process. But out of all of them, I've found these stages to be universally applicable:

Dreaming and Shaping

A piece of software starts, before any code is written, as an idea or as a problem to be solved. Its a constraint on a plant floor, a need for information, a better way to work, a way to communicate, or a way to play. It is always tied to a human being ≈ their job, their entertainment┘ their needs. A good process will explore this driving factor well. In the project I'm wrapping up now I felt strongly, and my employer agreed with me, that to understand what we needed to do, we'd have to go to the customer and feel their pain. We'd have to watch them work so we could understand their constraints. And we'd have to explore the other solutions out there to the problem we were trying to solve.

Once you understand what you need to build, you still don't begin building it. Like an architect or a designer, you start with a sketch, and you create a design. In software your design is expressed in documents and in diagrams. Its not uncommon for the design process to take longer than the coding process. As a part of your design, you have to understand your tools. Imagine an author who, at the start of each book, needs to research every writing instrument on the market first. You have to become knowledgeable about the strengths and weaknesses of each tool out there, because your choice of instrument, as much as your design or skill as a programmer, can impact the success of your work. Then you review. With marketing and with every subject matter expert and team member you can find who will have any advice to give. You meet and you discuss and you refine your design, your pre-conceptions, and even your selected tools until it passes the most intense scrutiny.

Once you have these things down, you have to be willing to give them up. You have to go back to the customer, or the originator of the problem, and sell them your solution. You put on a sales hat and you pitch what you've dreamt up┘ then wait with bated breath while they dissect your brain child. If you've understood them, and the problem, you'll only need to make adjustments or adapt to information you didn't previously have. Always you need to anticipate changes you didn't plan for ≈ they'll come at you through-out the project.

Once you know how the solution is going to work, or sometimes even before then, you need to figure out how people are going to work with your solution. Software that can't be understood can't be used, so no matter how brilliant your design, if your interface isn't elegant and beautiful and intuitive, your project is a failure.

I don't pick those adjectives lightly either. All of them are required, in balance. If its not elegant, then its wasteful and you'll likely need to find a new job. If its not beautiful, then no one will want to use it. And if its not intuitive, no one will be able to use it. The attention to detail required of a good interface developer is on par with that of a good painter. Every dot, every stroke, every color choice is significant.

To make something easy to use requires at least a basic understanding of human reactions, an awareness of cognitive norms. People react to your software, often on a very base level. If you don't believe me, think of the last time your computer crashed before you had a chance to save the last 2 hours worth of an essay, or a game you were playing. What you put before your users must be easy to look at so that they are comfortable learning it. It must anticipate their needs so that they don't get frustrated. It must suggest its use, simply by being on the screen. And above all else, it must preserve their focus and their effort.

So you paint, using PowerPoint, or Visio, or some other tool, your picture of what you think the customer is going to want to use, and once again you don your sales hat and try to sell it to them. Only, unlike a salesperson selling someone else's product, you are selling your own work, and are inevitably emotionally-attached to it. Still, you know criticism is good, because it makes the results better, so you force yourself to be logical about it.

Then finally, when your solution is approved, and your interface is understood, you can move on to the really fun part of your job:

Prose and Poetry

A good sonnet isn't only identified by the letters or words on the page, but by the cadence, the meter, the measure, the flow┘ a good piece of literature is beautiful because it is shaped carefully yet communicates eloquently.

Code is no different. The purpose of code is to express a solution. A project consists of small stanzas, called "Methods" or "Functions" depending on what language you use. Each of these verses must be constructed in such a way that it is efficient, tightly-crafted, and effective. And like a poem, there are rules that dictate how it should be shaped. There is beauty in a clever Function.

But the real beauty of code goes further than poetry. Because it re-uses itself. Maybe its more like music, where a particular measure is repeated later in the song, and through its familiarity, it adds to the shape of the whole piece. Functions are like that, in that they're called throughout the software. Sometimes they repeat within themselves, in iterations, like the repeating patterns you see in nature. fern.jpgAnd when the pieces are added up, each in itself a little work of art, they make, if programmed properly, a whole that is much more than a sum. Its is an intertwined, and constantly moving piece of art.

As programmers, we add things called "log messages" so that we can see these parts working together, because without this output, the flow of the data through the different rungs and branches we put together is so fluid that we can't even observe it and, like trying to fathom the number of stars in the sky, it is difficult to even conceptualize visually the thousands of interactions a second that your code is causing. And we need to do this, because next comes a Quality Assurance Engineer (or QA) who tries to break your code, question your decisions, and generally force you to do better than what you thought was your best.

I truly believe that code is an art form. One that only a small portion of the population can appreciate. Sure anyone can walk into the Louvre and appreciate the end result of a Davinci or a Van Gogh, but only a true artist or student of art can really understand the intricacy of the work behind it. Similarly, most people can recognize a good piece of software when they use it (certainly anyone can recognize a bad piece of software) but it takes a true artist, or at least an earnest student, to understand just how brilliant ≈ or how wretched ≈ the work behind it is.

And always, as you weave your code, you have to be prepared to change it, to re-use it, to re-contain it, to re-purpose it in ways that you can't have planned for. Because that is the nature of your art form ≈ always changing and advancing.

Publishing and Documenting

Its been said that a scientist or researcher must "publish or perish." The same is true of a software developer. A brilliant piece of code, if not used, is lost. Within months it will become obsolete, or replaced, or usurped, and your efforts will become meaningless, save for the satisfaction of having solved a problem on your own.

So after months of wearing jeans, chugging caffeine, cluttering your desk with sketches and reference material, you clean yourself up, put on a nice pair of pants, comb your hair, and sell again. Although most organizations have a sales force and a marketing department, a savvy customer will invariably want technical details that a non-coder can't supply. As a lead developer on a project, it falls to you to instill confidence, to speak articulately and passionately about the appropriateness and worth of your solution. Again, as before, pride is a weakness here, because no matter how good you are, someone will always ask if your software can do something it can't ≈ user's are never really satisfied. So you think back to the design process, you remind them when they had a part in the decisions, and you attempt to impress upon them respect for the solution you have now, while acknowledging that there will always be a version 2.0.

And you write and you teach. Not so much in my current job, but in one previous, as a lead developer it was my responsibility to educate people on the uses of our technology ≈ to come up with ways to express the usefulness of a project without boring people with too many technical details. One of the best parts of software development, a part that I miss since its not within my present job description, is getting up in front of people ≈ once they've accepted your solution ≈ and teaching them how to use it and apply it. Taking them beyond the basic functionality and showing them the tricks and shortcuts and advanced features that you programmed in, not because anyone asked you for them, but because you knew in your gut they should be there.

And Repeat┘

Then there's a party, a brief respite, where you celebrate your victory, congratulate those who've worked on parallel projects, and express your deepest gratitude for your peers who've lent their own particular area of expertise to your project┘ And you start again. Because like I'm sure any sports team feels, you are only as good as your latest victory.

So do I fix computers? Often its easier or more expedient to hack together a solution to a problem on my own ≈ certainly the I.T. Department is becoming something of a slow-moving dinosaur in an age where computers aren't the size of buildings, and most of us are comfortable re-installing Windows on our own ≈ but that's not a part of my job description.

No, I, like my peers, produce art. Functional, useful, but still beautiful, art. We are code poets, and it is our prose that builds the tools people use every day.

However, unlike most other artists, we're usually paid pretty well for our work ;-)

Slashdot The Life of a Software Engineer

• A++ tags, would read again (Score:5, Funny)

  by Osurak (1013927) on Monday February 04, @02:25PM (#22295660)

   

  programming, douchebaggery, pompouswanker, whining, slashdotted

  How appropriate.

• Obligatory Futurama Quote (Score:4, Interesting)

  by ari_j (90255) on Monday February 04, @03:28PM (#22296856) Homepage

   

  Jonathan Wise writes to share with us an interesting bit of prose describing life as a software engineer.

  Interesting. No, wait, that other thing. Tedious.

   

  A software developer must be part writer and poet, part salesperson and public speaker, part artist and designer, and always equal parts logic and empathy.

  No. You're a code monkey. Your poetry sucks, your writing sucks (to the point of your having written "its for the best"), your salesmanship sucks (your article sells nobody on anything), your public speaking is probably twice as melodramatic as your article and therefore sucks, your art sucks, your designs are plagued with whining about having to make them, and you have never experienced logic or empathy as long as you've lived.

  Get over it. If you want to make your pathetic job seem more important than it is, Slashdot isn't the place to do it. If you want to whine about being a code monkey, Slashdot is even less appropriate of a place to do it. Just get up, get coffee, go to job, and have boring meeting with boring manager Rob.

• Poetry and Prose... (Score:2)

  by flajann (658201) on Monday February 04, @04:55PM (#22298404) Homepage Journal

  I can tell many of the posters did not bother to read the full article. Perhaps your excuse is because his site crumbled under the "slash-dot effect", but still.

  Having actually read what Jonathan Wise wrote, I thought he made quite a few good salient points. Going from idea to finished product is as much about art as it is about science. There is artistry involved at many different levels. Alas, the end-user only gets to directly see the top layers of that art. The actual organization of the code, the algorithms used, to optimizations, the kludges -- if any! --, the language constructs exploited, the database schema, if applicable, all add to the art and elegance of a software.

  Most of the beauty will forever lie hidden from any but those who dive into and interact directly with the code itself. But the end-user will be presented with the form and function, and perhaps can have a appreciation for the art behind the art.

  Perhaps another term for what we do, which embraces all aspects of creating software, is hacker. To the cognoscenti who appreciates the true meaning of that term and not the disparaging, derogatory version the silly media created, "hacker" says it all. And is a greater thing than just being a dry boring "engineer". After all, we are not building planes and bridges, but creating "art" that just happens to be wicked useful and pay wicked well!

• Even Burger Engineers are multi-skilled (Score:2)

  by EmbeddedJanitor (597831) on Monday February 04, @02:39PM (#22295872)

  Flipping, charring, till operating, cleaning and eating the shit from customers while keeping a smile on your face. All jobs require multiple skills.

  Silly whining poster probably just got out of college and is used to mommy and daddy telling him he's the greatest. Now in the real world he's just another bottom-of-the-pile programmer. Life: get one!

• Re:Software is different for a damn good reason (Score:2)

  by orclevegam (940336) on Monday February 04, @03:10PM (#22296486)

  (To expand on the ideas of your post)
  A great deal of crap software is actually pushed out the door against the objections of the developers that created it. Ultimately it comes down to marketing and PR and not the developers in most cases as to when a particular piece of software is ready to ship. Also, as has been pointed out, people would be unwilling to underwrite the cost of a theoretically "perfect" piece of software that would never crash (barring hardware failure, or cosmic ray induced bit flipping), because given the choice between a $50 piece of software that crashes once a week, or a $9000 piece of software that crashes never, almost everyone is going to pick the $50 one and live with the occasional crash. Does that mean developers like that? No, and most of them cringe whenever anything they wrote so much as hiccups, but sometimes they're just not given the chance or the resources (or clear documentation) they need to design it properly, because the bean counters know that the $9k piece of software the developer dreams of will never sell, but that $50 one they're puttering around with now is just about the right level already.

• Perfection vs. due diligence (Score:2)

  by Anonymous Brave Guy (457657) on Monday February 04, @03:47PM (#22297216)

   

  Also, as has been pointed out, people would be unwilling to underwrite the cost of a theoretically "perfect" piece of software that would never crash (barring hardware failure, or cosmic ray induced bit flipping), because given the choice between a $50 piece of software that crashes once a week, or a $9000 piece of software that crashes never, almost everyone is going to pick the $50 one and live with the occasional crash.

  I really hate it when these discussions become black and white. Software quality is not a binary value. It is a sliding scale with diminishing returns for effort put in, on which we are for the most part still at the "dirt cheap" end.

  I doubt I would want to pay the price of near-perfection. I'll leave that for the nuclear reactors, medical facilities and space shuttles. But the cost of due diligence — which I'll assume to mean taking reasonable, well-established, tried-and-tested steps to ensure quality in this context — is not the factor of 180 you gave. It's probably not even a factor of 5, and that's today when it's a relative overhead compared to those who don't bother.

  What it would mean is having to actually follow reasonable development processes that worked. No more buzzword kool-aid for you, Mr Engineer! It would mean hiring competent people as senior technical staff instead of promoting substandard but slightly cheaper code monkeys, and spending the time and money to train those working under these senior staff properly. It would mean not letting sales and marketing staff dictate the schedules at the expense of even basic quality control.

  Of course, if everyone were doing this and the industry as a whole grew up, this wouldn't cost much at all, because those same good practices actually make software development more efficient. It's just that short-sighted managers with their eye on quarterly reports and personal bonuses have an active incentive not to make the long-term investments necessary to reap those long-term benefits.

[June 2005] Programmers are People, Too

As API designers we may talk about a trade-off between simplicity and power, but we can look to human factors to find tools to address it. One such tool is progressive disclosure: rather than put expert-level features at the same level as basic ones, you put them behind a door marked “expert.” Consider the car, where most folks can work with the controls in the cabin but, with a few exceptions (such as washer fluid), they never need to open the hood. You know the engine is there, but most people just leave that part alone. A few experts do open it up and adjust the car with these expert-level controls, and if you want to do it, you know where to look. But if operating a car presented you with the entire engine as a control structure, most humans would find driving dauntingly complex, even if they just had to learn not to look at “all them wires and tubes and valves and things.”

You see progressive disclosure fairly often in GUI designs, typically as an Advanced or Expert button. This might expose settings for Web proxies in a browser or a rarely needed configuration for adjusting color balances on a printer.

We could do the same thing with APIs. For example, the Java Swing JButton class—the basic GUI button—has well over 100 methods. But if you think about GUI buttons, there are only a half-dozen things you typically care about most of the time. When presented with this massive complexity, how are you to tell where to start? Should you be adjusting the preferred or minimum size? What happens if you change the text? Do you need to fire those things called “change listeners,” and if so, which kind?

To start getting this nonsense under control, you can start by breaking the JButton methods down into three major groups:

• The basic methods needed by most of us (set text/icon, add a callback listener for when the button is pressed).
• The expert methods for folks who want to get in and tweak (the font, color, border style).
• The integration methods needed by folks who write GUI widgets in Swing, who are a very rare breed of programmer (sizes, firing off change listeners, re-parenting).

Now we could use progressive disclosure to help reduce the complexity of that JButton class: put the expert stuff in an object returned by a getExpertKnobs() method, and the graphics subsystem hooks in an object returned by a getIntegrationHooks() method, and you would be left with a button API that had just a handful of methods—the basic methods we all need.

The overall system would be a bit more complex if you simply count methods and types, but you should not fall into the trap of thinking all methods are the same. If you look at what is presented to the programmer, the system would go from well over 100 methods to consider when using a button to fewer than 10. All the power would be present and available, but only when you wanted it. For the most part, you could ignore it completely because they would be behind “doors” labeled, “You probably don’t need to look here.” If one were sufficiently brutal in exiling functionality to behind the doors, the API would almost be self-explanatory to the nonexpert user. (To be fair, Swing is not unique in its complexity. This malaise seems to infect most GUI frameworks of note, including the Microsoft Foundation Classes, the X11 toolkits, and so on.)

What progressive disclosure does here is reduce the surface area, a term I use to talk about how much users have to understand about something before feeling confident they can use it. The more methods in an API, the more a user has to read through and understand before knowing, for example, if changing the label is something as simple as calling setText or if one those other methods affects this. The larger the surface area, the harder it is to learn to use the tool well for even simple applications.

SECOND EXAMPLE: THE AUDIENCE

Another human-factors approach that could be applied to programmer tools is to consider the audience (sometimes called the user model). A good UI design has a notion of audience: What kinds of people are we designing for? What do they know, not know, and expect? If a UI has a clear and consistent audience, it is easier for users to make predictions about what the system will do. This reduces unpleasant surprises and means that the users can guess how to do things without reading the documentation (which they hardly ever do). Sounds like a pretty good feature in a programming language or API, doesn’t it?

This can work even if the user is not a part of the targeted audience. If you present a consistent model of some known kind of user, other kinds of users can potentially adapt, consciously or otherwise thinking via the role of the target user.

If you apply this question to C++, for example, you will find major problems. Sometimes C++ believes that programmers like to have the compiler do obvious things on their behalf and correct the compiler when it’s wrong. C++ will, for example, generate a default copy constructor that can create a copy of your type of object. Yes, the default copy constructor can be wrong, but it is right fairly often, so the language gives you a hand. If it’s wrong, any C++ programmer should know enough to provide a replacement that does work properly.

At other times C++ has a different model of the user: it believes that it should do nothing that stands a chance of being wrong, no matter how many times an obvious assumption would be right. One example is what doesn’t happen if you define how to check if two objects are equivalent (overriding the == operator). It seems obvious that knowing if two objects are equivalent would let you know if they are not equivalent. That is, knowing how to test x == y, then x != y can be thought of as !(x == y).

But C++ does not define != for you because it is possible in some odd cases that this is not true, though the number of such cases must be infinitesimal. It is surely wrong in many fewer cases than the default copy constructor is wrong.

So is C++ a language that helps you with obvious things that are usually correct, or one that is more concerned with formal correctness? As an example, take a guess: if you define a constructor that can create a new Foo object from a Bar object, does C++ use it to automatically define how foo = (Foo) bar will work? Put another way, does it override the = operator for assigning a Bar to a Foo? Is your gut instinct different for these two questions?

This kind of inconsistency makes a system harder to learn and harder to use correctly. Instead of a consistent, comprehensible model of the audience that the user can grasp, you have instead a large collection of special cases where you can neither predict nor use some rule of thumb as a hint.

WHERE TO GO WITH THIS?

When you use a GUI that has profound inconsistencies about what level of expertise and control you have, or presents you with a dialog box with 100 options when you just want to change the display font, is it fair to say that the designer made a mistake? Then why not judge the API or language designer the same way?

The problem is that these basic rules of thumb and experiences in human factors are not part of the design discourse about the primary tools we build for ourselves: programming languages and APIs. We ought to change this. If we can learn from human factors to do things better, we will be able to write code with fewer bugs. And because it will be easier, we can spend less time learning how to do stuff and more time doing it. The study of human factors is for humans, not for GUIs. And (see above) programmers are humans.

So let’s proceed from the following theorem: An API or programming language is a user interface to the programming model that is being presented to the user (the programmer).

Let’s look at several typical rules of thumb for human factors and see how they might be applied.

Similar things should look similar. If two things mean the same or very similar things, they should be presented in ways that express that similarity. In a GUI this would mean that no matter how many ways and reasons there are to open files, the basic interaction for opening files should be the same. For an API this might mean that if there are multiple things that can be started and stopped, then the same terms should be used for each kind of thing. It would be important to pick, for example, “start” and “stop” and use them for all starting and stopping, rather than have some places where you end execution using “end” or “terminate” or “close” or “destroy.”

As a negative example, C has two rather different variable declaration mechanisms: one used for declaring function parameters (which is comma-separated), and another used for all other variables (which is semicolon-terminated). Although we’ve all learned this, it is one of those small things that you can stumble over. Everywhere but in function parameters you can declare that x and y have the same type via “double x, y;” but in method parameters it must be “double x, double y”, which loses the connection between the types of variables. In the first form you can change coordinates to be held in float variables naturally, whereas in the second form you must change the types of x and y independently, as if it somehow might be reasonable to change only x.

Use forcing functions to prevent errors. You could think of this as the “This button turns on the bathroom light, and that button launches global thermonuclear war. Don’t mix them up!” rule.

A forcing function makes the user do something that prevents (or makes unlikely) some type of mistake. Many cars, for example, will not let you take the key out of the ignition unless the car is in a correct gear. This makes it very unlikely that you will leave the car in neutral when you leave your car, only to watch it slip down the hill and into your mother-in-law’s new Lexus.

In programming you can apply this to many areas. In many languages you can make it impossible to write certain kinds of incorrect code. In C++ the presence of const is intended for exactly this purpose. If the compiler simply won’t let you make a modifying call on an object, and you hand out only const references to your objects, then users can’t make the mistake of modifying something they shouldn’t. (Well, at least not casually—you can cast away const, but this is clearly suspicious behavior, so you’ve at least made them do something that raises alarm bells. This is still a forcing function.)

Another example is quite common: if you don’t have the right token, you can’t perform a particular action. Any time you see a function that requires a certain type of handle that you can only get somewhere specific, you are being forced to do something first. In Java, for example, you can open with a File object, but you can close only the resulting FileInputStream object, not the File object. This makes it impossible to write code that closes a file without opening it first.

Think from the user in. Interestingly, the forcing function principle also demonstrates the difficulty of actually applying human-factors principles. Reading a file is a very different category of action than destroying existing files, which risks much more damage. The normal forcing function approach would be to make it more awkward to destroy a file than to read one. Maybe we could make destroying files a multistep process or use longer function names that would never be accidentally typed.

Programmers, however, are not just humans, but notoriously lazy and problem-solving humans. In the face of such a design, programmers would write single methods that combine all the steps, or create shortcuts for long method names, or otherwise remove the “problem” of awkward access. I know I would. So in applying this principle we are limited by both our “materials” (programming languages) and our audience.

In other words, your audience has particular features: habits, assumptions, knowledge (correct and wrong), and customs. Programmers are human. They also are particular kinds of humans. And the user of some particular API is yet further specifiable.

The one thing they are almost certainly not, however, is you. You are thinking about how to solve the problem, the merits of various approaches, the detailed trade-offs between one algorithm and another, the literature on doing the work involved, and so on. By the time you are done figuring out what to do, you are likely one of the most expert folks in the world on the task you are trying to help people with.

And your users? They just want it to happen. They will have varying degrees of expertise, but even the most expert will have one reason to use your system: so they can think about it as little as possible. If you have done your job well, their use of your code will be only as large as you make them make it. Remember, if possible, your users would want you to provide a single command: dwim (do what I mean).

So you must think like your user: think in to the problem from their desires and viewpoints rather than out from your sophisticated understandings of solutions and mechanisms. Your design should ask, “What does the user want to do?” instead of “How can I present Whilfolze’s 3rd Equation to optimize applications of Guilemorting’s Principle?” If Whilfolze and Guilemorting have useful things to say about solving the user’s actual problem, you should apply their insights instead of making the user tell you how to apply them. The user should say “solve this,” and your code should use Whilfolze and/or Guilemorting if that’s a good thing to do.

Consider the difference between a car designer asking, “How does the user control the car?” vs. “How can the user adjust the fuel intake, injectors, cylinders, spark plugs, fans, differentials, etc.?” The first question is much more likely to produce a design usable by car-ignoramuses like me because the question it asks is one I will ask. Approaching the design as a way to fiddle with the complex car parameters will almost certainly produce a more complex design with more alternatives and features presented to me. I don’t want that. If I want to become a car expert, I will open the hood. I just want the thing to work.

One way to approach the problem is this: write the pseudocode your users would want to write, and then make it work with as few additions as possible.

The primary questions are: What problems are users trying to solve? What kinds of things do users have in hand when they want to solve the problem? How does the user think of the problem? What must the user tell me and what can I deduce for myself? This starts with a good definition of who your users are, of course, which is a task most designs seem to ignore.

Remember that users have a notorious history of thinking they know how something should be done and being wrong. One classic example is the register keyword of C. The idea was that the user (in this case a programmer) would tell the compiler which local variables should be stored in fast-access processor registers because the programmer knew what was critical. It turned out that compilers were almost always smarter about register allocation than users could ever be. The register keyword quickly became advisory, and by now I suspect that all C/C++ compilers just ignore it, snickering.

[Apr 05, 2007] Working for The Man Advice to a young programmer Tech News on ZDNet

Commentary -- Making a career out of writing software? Remember that the community is more important than your employer.

Working for Google is full of surprises. When I first arrived I started to get to know my office-mate. He's a laid back, rather cool but studious-looking guy with longish hair. I asked him what he did and learned a lot about how students were taught parallel processing in a cluster environment. Politely he responded with the same question and I started to tell him about Samba and what I was currently working on. "You remember around 1988 when AT&T came out with a file-sharing protocol called RFS (Remote File System) to compete with NFS (Sun's Network File System)..." I continued.

"I was eight years old in 1988," he replied.

After I'd finished checking for obvious facial wrinkles in the bathroom, I decided to go on a quest to find other engineers in the building who were at least as old as I was, and felt much better when I found some. But it set me thinking about what kind of advice I would give if I could meet myself at his age, in order to guide the young Allison into a promising engineering career. So, in the best spirit of "The Screwtape Letters," here is some of what I've learned so far about making yourself a career in writing software.

If it's not what you love, don't do it
 

I've worked with many programmers during my career. Without a doubt, the only ones who are any good at it are those who see writing code as art, a creative process. I know it's an obvious lesson, but it's really important. If you want to make lots of money and retire early, don't start by writing software; learn about business and start a company instead. I've run into so many poor programmers, in both senses of the word, who got into the field because they "wanted to be the next Bill Gates." Bill Gates didn't get rich by programming, he got very rich by being very good at running a company. I've had to fix code created by these people and it isn't pretty. Eventually they usually move into management where they might have a chance to find their true calling.

Learn the architecture of the machine

Many programmers, especially those who write for virtual machines such as Java or the .NET CLI, think that low-level machine architecture and processor instructions don't matter anymore. That's still not true, and I don't believe it ever will be. Someone who understands what the machine is really doing underneath all the modern layers of glop such as virtual machines, garbage collection algorithms, network and threading abstractions, will always be able to solve problems better than someone who lets the compiler or the "execution environment" they're using make all the decisions for them. These days the effects of processor caches and memory bandwidth mean that it's even more important to understand the lower levels of computer architecture than it used to be in order to be a good programmer. The good news is that modern tools like the amazing free software tool "valgrind" can emulate an entire processor in software and make understanding what is going on at each line of code as simple as looking at a visualization of execution time. Using resources efficiently matters when you're dealing with modern clusters containing thousands of machines.

Reputation is important

The days of starting at IBM after college and working there in obscurity until you retire are long gone. Any modern programmer will move between many companies in his or her career. It is very important to be able to show your next employer what you have done, and what you are able to do in a team. Free software/open source is the ideal way of doing this. It's not just a better way of producing software, it's actually better for the reputation of the people creating it. One of the first things I do when evaluating someone is to look for samples of their code out there on the Internet. If you work on proprietary software you can't show anyone anything, and real code speaks louder than any list of projects you claim to have worked on.

Comments:

Working for The Man? Advice to a young programmer

What about the side effects of programming? The long hours at the office, staring at a computer screen for hours on end, and the one thing I'd be most concerned with is carpal tunnel. Then there is lower back pain from sitting in a chair for too long. The health risks are just as important.

Posted by: Loverock Davidson Posted on: 04/05/07

====

Art? Since when is that part of so-called 'corporate culture',

which is not driven by art but by money and how marketable something is. And as we've often seen, marketable does not always equate with quality.

Or if something if released, corporations should promise to fix it before adding new abilities to it.

Having said that, I see the logic behind hopscotching jobs. Trouble is, with some jobs so far away, anyone with a family may not be able to uproot themselves. And families are part of communities too. Or is some group of people not satisfied with the already high number of divorces and other family fall-outs; hoping this scenario will do the trick?

Posted by: HypnoToad72 Posted on: 04/05/07

 

Rick's World - Post details What makes a good programmer

Housemarque

Landing a programming position at Housemarque

At Housemarque we mainly develop full scale, console games for international market. A typical game may take 1-3 years to develop and may consist of 100k-300k lines of code. The competition in this market is tough, so we place tough requirements on our programmers.

Requirements

We do not require a degree in software engineering or computer science. We do, however, require:

• You to actually demonstrate your ability to develop high quality designs and code in the form of a programming sample,
• Knowledge of general software engineering techniques and principles and interest in game development.

In addition, since nearly all of our development is currently done in C++ and in english, we require:

• good C++ skills
• good English skills.

Pluses:

• Published titles
• Console game programming experience
• Professional PC game programming experience

Demonstrated exceptional skills in:

Computer graphics

• Artificial intelligence
• Algorithms and data structures
• Multiple distinct kind of programming languages (e.g. assembly, imperative, OO, functional, etc...)
• Advanced programming techniques (e.g. generative programming)
• Physics
• Math

Questions we'd like to be asked

What makes a good programmer in our view? The most important characteristic of a good programmer is the constant desire to learn more. If you think that you know everything there is to know about programming and/or have not read more than 2 programming books in the last 12 months, then it is unlikely that we would hire you - but in case you really know everything, then we would like to know whether P is NP (formal proof required). A good programmer is well versed in many areas of programming. ,

How do you evaluate programming samples?

All candidates are required to submit a source code sample of their programming. Without the sample, we can not make an assessment of your programming skills and can not consider you for a programming position. Performing a code review of a non-trivial programming sample is generally the most accurate way to assess the programming skills of an applicant.

A programming sample should preferably be in C++, because that is the main language we use in game development, but we accept programming samples in other languages.

ryanlrussell What makes a good programmer

Aha! I just found a quote from Joel which puts into words what makes a good programmer.

You need training to think of things at multiple levels of abstraction simultaneously, and that kind of thinking is exactly what you need to design great software architecture.

The quote can be found in this blog post.

Software quality has almost nothing to do with algorithmic elegance, compactness, or speed — in fact, those attributes do more harm to quality than good.

The objective is to make things as clear as possible to the designer and to yourself, and excessive formality can destroy clarity just as easily as modest formality can enhance it.

[The Spec] Be literal in your interpretation and smile when the designer accuses you of semantic nit-picking.

In programming, it's often the buts in the specification that kill you.

Don't squeeze the code. Don't squeeze the code. DON'T SQUEEZE THE CODE.

Like so much in testing, the act of getting the information on which to base tests can be more effective at catching and exterminating bugs than the tests that result from that information. Insisting on getting transaction flows or the equivalent is sometimes a gentle way of convincing inept design groups that they don't know what they're doing. These are harsh words, but let's face it: superb code and unit testing will be useless if the overall design is poor. And how can there be a rational, effective design if no one on the design team can walk you through the more important transactions, step by step and alternative by alternative. I'm sure that mine is a biased sample, but every system I've ever seen that was in serious trouble had no transaction flows documented, nor had the designers provided anything that approximated that kind of functional representation; however, it's certainly possible to have a bad design even with transaction flows.

Boris Beizer: Software Testing Techniques 2E. Van Nostrand Reinhold, New York 1990

Overpaid and underworked csmonitor.com

Overpaid and underworked?  

The salary often seems greener on the other desk, but studies show that may not be true.
 

By Marilyn Gardner | Staff writer of The Christian Science Monitor
 

When the subject turns to salaries, an IT consultant in the New York area sums up the feelings of many workers when he says, "I'm probably paid a little less than I'm worth."

Now he wants to change that. "I'm exploring my options," the consultant says, asking to be identified only as Eric because he fears he could jeopardize his current position if his firm finds out he is job-hunting.

Eric has plenty of company. A survey released Monday by Salary.com reveals that nearly 60 percent of workers seeking jobs claim they are underpaid. But in a surprising twist, the salary data website finds that nearly 20 percent are actually overpaid. Less than 20 percent are underpaid.

"Phrases like 'overworked and underpaid' perpetuate that feeling," says Lena Bottos, director of compensation for Salary.com. The online survey of employee satisfaction and retention polled nearly 14,000 workers and some 400 human-resources managers in a wide range of industries.

Salaries have long been cloaked in secrecy for many workers, making comparisons difficult. Now, online salary data sites enable workers to measure their pay against comparable positions in their field and location.

"You network with your peers, and absolutely they talk about salaries," Eric says. "At least they talk about ranges. Just looking around at what ranges are offered, you have an idea of the market rate. The consensus among my peers is that the way to get a good raise is to switch companies."

Another survey, done in 2005 by Hudson Highland Group, finds that only half of workers believe they are paid on a par with their peers.

The number of employees in the Salary.com poll who describe themselves as "very likely" to leave their current jobs increased more than 50 percent in the past year.

"There are a lot more new jobs," Ms. Bottos explains. "People see that the market is starting to pick up. The grass is always greener."

At the same time, employees are becoming "a little bolder" in terms of what they think they are worth, says Jeff Cooper, a senior business consultant at Authoria, a talent-management software company in Waltham, Mass.

Employers themselves have unwittingly created some of the confusion. When the economy slows, some companies inflate workers' titles in lieu of salary increases. Salary.com finds that nearly 30 percent of respondents are "over-titled."

"When a manager wants to reward an employee and doesn't have the budget to do so, you tack on 'supervisor,' 'manager,' 'director,' or 'senior' to their title," Bottos says. "But the problem then arises that you've given someone this 'manager' title, but they don't manage. You've created a disconnect between what their title is and what their salary should be."

Workplace experts caution that titles are deceiving and vary from company to company. "In the end, a title is what goes on someone's business card," says Lauren Williams, a managing partner with Princeton Search Group, an executive search firm. "It speaks very little to their abilities. What could be a manager in one company could be a director in another. An executive assistant in one company could be a receptionist in another. But responsibility is responsibility. That's what people can be accounted on and compensated for."

Whatever their title, many employees who are dissatisfied with their income say that a 10 percent raise would be enough to keep them for another year, according to Salary.com.

Bottos calls that "an interesting number, because it isn't outrageous."

Joel on Software A good introduction to Dr. Deming's philosophy of management: Four Days with Dr. Deming summarizes the four day seminars Deming used to give to business leaders.

• Key insight: you can't improve your team's performance just by picking some numeric measurement and then rewarding or punishing people to optimize it.
• Problem one: the variability in the measurement may be caused by a broken system that only management can change, not by individual performance.
• Problem two: people may optimize locally to improve that one measurement, even at the cost of hurting the performance of the company as a whole.

If you're in a rut constantly trying to figure out how to rejigger your employees' incentive systems, this book will get you out of it.

Lord Palmerstron Syndrom

Lord Palmerston: "The Schleswig-Holstein question is so complicated, only three men in Europe have ever understood it. One was Prince Albert, who is dead. The second was a German professor who became mad. I am the third and I have forgotten all about it." Programming has gotten too hard.

Student Syndrom

"Student Syndrome" - no matter how long you give students to work on something, they will start the night before.

Phil Greenspun noticed this: "The first term that we taught 6.916, we gave the students one week to do Problem Set 1. It was pretty tough and some of them worked all night the last two nights. Having watched them still at their terminals when we left the lab at 4:00 am, we wanted to be kinder and gentler the next semester. So we gave them two weeks to do the same homework assignment. The first week went by. The students were working on other classes, playing sports on the lawn, going out with friends. They didn't start working on the problem set until a few days before it was due and ended up in the lab all night just as before."

The Law of Leaky Abstractions

Abstractions fail. Sometimes a little, sometimes a lot. There's leakage. Things go wrong. It happens all over the place when you have abstractions, and it's dragging us down. Read all about it in my latest feature article: The Law of Leaky Abstractions.

Front End Programming Sucks

Author:   James Fristrom    

Posted: 2/6/2002; 8:06:22 PM

Topic: Front End Programming Sucks

Msg #: 55 (top msg in thread)

Prev/Next: 54/56

Two facts.

Fact #1: You can't trust the front end to a mediocre programmer. They'll take at least twice as long to get it done, it will be shoddy, it will violate the console manufacturer's Technical Requirements Checklist.

Fact #2: Good programmers don't like working on the front end.

You could say that you shouldn't hire mediocre programmers in the first place. But then who will work on the front end?

So what do you do?

I wish I knew. I've worked on three projects where vital front end functionality was missing and broken right up to the wire. This latest time was worse than most: we ended up firing the front end programmer and dividing his remaining bugs between the lead and two trusted coders.

Why isn't professionalism - the virtue of enjoying a job well done - enough to keep good coders happy with doing front ends? I guess we didn't get into this industry to be professional, we did it to work on cool games.

Maybe it's that front ends don't seem 'challening' enough. But front ends aren't without challenges: front ends often mix three-d and two-d elements, stream data and audio at the same time, have stunning graphics.

"I was meant for more important things," I hear programmers say. The most visible system in the game isn't important enough. Doesn't require their advanced skill set.

My dream front end programmer might be someone from the web design community, but someone who also was skilled at C++. Someone who didn't mind working on tools. (The same problem I outlined above also holds true for tools programming...it's vital to your success but nobody wants to do it.) Someone who had enough design sense to make decisions without being micromanaged by an art director. Does such a person exist? And could a game development company afford them, or is web programming far too lucrative?

Actually, my dream front end programmer would be a clone of myself with a pay cut.

(Michael Vance pointed out that this last sentence is obnoxious. He's right, it is obnoxious, but I'm going to leave it up here out of shame.)
Posted by James Fristrom on 2/6/02; 8:19:41 PM
from the dept.

I've heard widely varying opinions on why software is so lousy, the most recent from this article by Charles C. Mann. Mr. Mann makes an excellent anecdotal case for just how bad software has become. Then, he concludes that perhaps a bit more litigation would help matters. While one of the perpetrators of bad software he cites is Microsoft, they, and other wealthy software development companies, might be among the least vulnerable to lawsuits brought over poor software. As is frequently the case, increased litigation would probably put the small developer at even more of a disadvantage relative to the large software corporation.

But more to the point, why is software so bad? Programming is sometimes compared to an engineering specialty and the point is made that product standards are much lower for software. Software, unlike building construction, for example, is pure design. The actual programming phase is just a finer grained version of what we programmers normally call 'design'.

Software development is one hundred percent design.

Consider the implications of that statement for a moment. Virtually all of the cost of software development is, directly and indirectly, the cost of design. If a student architect could design a skyscraper, push a button, and have some futuristic genesis device instantly construct the building at virtually no cost -- and at no danger to anyone -- and with perfect components throughout, would he not do so? Further, imagine that with a push of another button, the entire building could be reduced back to its constituent atoms.

The student could try and try again, refining his design until it was finally just what he wanted. Now, imagine that there was no danger in occupying such a building. Would it change the way we make buildings? Given the alternative of spending millions to build the building the old fashioned way versus spending a fraction of one percent of that to do only the design -- and automate the remainder for virtually nothing -- I suspect that the market would choose the vastly cheaper method.

For software that doesn't involve life-or-death applications, the development cost model closely resembles our fictional architectural scenario.

People are understandably reluctant to add real engineering discipline to software development. While there is no physical building phase, the complexity of a large application is staggering. A large program might have millions of (logically) moving parts, all interrelated. To prove that it all works correctly, as specified, might be more than just prohibitively expensive; it may well be impossible. And even if such verification were possible, proving the correctness of a large program would greatly delay the release date.

Perhaps life support systems, X-ray machines, and other such critical programming does belong in the engineering realm with formal education requirements, legal responsibilities, and state certification. But for my favorite projects, I think the status quo is just fine.

Yes, software sucks -- but it's usually cheap. Further, in my experience, the cheapest software, free, seems to suck the least.

Fast, good, cheap: choose two.
 

Recommended Links

---

In case of broken links please try to use Google search. If you find the page please notify us about new location

• Academician A. Ershov's archive Documents (raw images of the ACM article)
• Aesthetics and the human factor in programming by Andrey Erchov (in Russian)

Donald Knuth Computer programming as an art  Famous Turing lecture by the author of the "The Art of Computer Programming"  masterpiece...

Experience of programming beauty: some patterns of programming aesthetics

p35-rudd

Housemarque How to be a Programmer: A Short, Comprehensive, and Personal Summary Hitting the High Notes - Joel on Software

What makes a good programmer?

Something in the way it fails,
Defies the algorithm's logic!
Something in the way it coredumps... 
I don't want to leave it now
I'll fix this problem somehow
Somewhere in the memory I know,
A pointer's got to be corrupted.
Stepping in the debugger will show me... 
I don't want to leave it now
I'm too close to leave it now
You're asking me can this code go?
I don't know, I don't know...
What sequence causes it to blow?
I don't know, I don't know...
Something in the initializing code?
And all I have to do is think of it
Something in the listing will show me... 
I don't want to leave it now
I'll fix this tonight I vow!

Eleanor Rigby
Sits at the keyboard
And waits for a line on the screen
Lives in a dream
Waits for a signal
Finding some code
That will make the machine do some more. 
What is it for?
All the lonely users, 
where do they all come from? 
All the lonely users, 
why does it take so long?
Guru MacKenzie
Typing the lines of a program 
that no one will run; 
Isn't it fun?
Look at him working,
Munching some chips as he waits 
for the code to compile; 
It takes a while...
All the lonely users, 
where do they all come from? 
All the lonely users, 
why does it take so long?
Eleanor Rigby
Crashes the system and loses 
6 hours of work; 
Feels like a jerk.
Guru MacKenzie
Wiping the crumbs off the keys 
as he types in the code; 
Nothing will load.
All the lonely users, 
where do they all come from? 
All the lonely users, 
why does it take so long?