As a programmer I have an inherent nagging annoyance at my tools, other peoples code, my code, the world in general. I always want to improve it. So I refactor, I stay on top of the latest techniques. I try and learn patterns, I try to use frameworks so as not to reinvent the wheel. I can write a tech spec that will blow your socks off with the amount of patterns I can squeeze in.

However, lately I feel I actually know more about the tools I use than how to actually implement successful software.

I feel like I'm lacking in the human factors skill set and I believe that to be a successful software engineer takes more than knowing the coolest framework. I think it needs some of the following skillsets too.

  • Interaction design
  • User experience
  • Marketing

I've got a bit of this that I've learned from people I've worked with and great projects I've worked on but I don't feel like I "own" these skills.

Am I right? Should I be trying to develop these skills further, or should these be left to the people who do these for a career?

How do you make sure you don't get too tied up in how you're doing something and make sure you "make your users awesome"?

Does anyone know of good resources for learning these skills from a programming point of view?

  • 2
    Yes, those are a big deal. If you were a one-man-company, then you would have felt the pinch right away. A start-up might not hire you because you do not get that it is fighting to survive and they either have to push out beta-quality stuff next month or die, or because you cannot stretch the truth a bit when talking to the customers. However, in a large corporation that is mismanaged, perhaps it is better to pursue selfish self-interest. Management does so all the time anyway. – Job Feb 8 '11 at 15:41
  • I enjoy using great products, where i think "wow, that works smoothly". So trying to participate in creating such "wow"-products comes natural to me. If this is not natural to you, maybe just keep those in mind, who enjoy this and are willing to pay good money (think Apple products). – LennyProgrammers Feb 8 '11 at 16:04
  • 2
    It sounds to me you are on the road to being a process-oriented worker, instead of a results-oriented worker. You focus on the process because that's what you are familiar with. Learn to let go of the process and focus on the results. As you said, design patterns and stuff are merely tools: your main concern should be on what problem the product you are making will solve. – whatsisname Feb 8 '11 at 17:44
  • 1
    @whatisname, its not that simple, sure the "results" may seem that such and such application works great for ver 1.0 with some ad-hoc code that was hacked together but then for ver 2.0 a major change is needed, well you are still going to be stuck with a "result" of the previous effort that will need re-working.. I think its really a situation where the functionality of an application from a user's point of view is only the tip of the iceberg and you can't constrain the "result" to just that – programmx10 Feb 8 '11 at 19:50
  • @whatisname If that had have been an answer I would have accepted it but I agree with you Rick also. What I'm trying to get to is a point where one of the 2 sets of skills are in balance so I'm able to design a great user experience while using the best tools and techniques. It seems right now that one or the other is suffering. I need to make both skill sets second nature. – Rob Stevenson-Leggett Feb 8 '11 at 21:59

My bit of advice: Talk with your users as much as possible. I don't know if you're at a large company and are on a different continent than your users, or if you're in a freelancer-type position, but if at all possible, just talk with your users.

I know that a lot of times, I have to kind of sit back and remember that it isn't my job to build the greatest bit of code the world has ever seen, or build a function that uses the least amount of cycles and takes the shortest amount of time technologically possible, but to make whatever the users need to do their jobs. And to that effect, I find that beyond sheer technical capability, (for myself anyway) the best 2 traits to have are a good working knowledge of the users' business, and a good working relationship with them.

I work in a smallish (~50 person) company, and I like being able to walk up to anybody's cube and chat about the latest thing I've made/fixed for them. The absolute best feeling I have ever gotten from my job is when I am able to hear them talking about their work, and suggest something that will solve a problem they never realized a technical solution could even exist for. That wouldn't be possible if I did not understand their business and could not have casual conversations with them.

  • +1 for talking with users - critical for creating a useful product – Gary Rowe Feb 8 '11 at 18:11

I'd say it depends on where you work, and what types of companies you see yourself moving to in the future - which is really an open ended discussion.

With smaller companies, you may to wear many hats (though I'm not sure why marketing is in this list unless you intend to sell your own product).

In bigger companies, they may tend to have people who focus specifically on these things.

So really, it's all about where you see yourself going, and potentially opening more doors for yourself.

  • 2
    Thanks - interesting points. I view marketing as more than selling, I'm thinking development blogs, SEO, Affiliates, how they should be integrated, etc. – Rob Stevenson-Leggett Feb 8 '11 at 15:53

For every line of code you write you introduce the chance of a bug.

So, the best designs minimise the amount of introduced code - perhaps through the DRY (Don't Repeat Yourself) principle. However, startups favour the YAGNI (You Ain't Gonna Need It) approach which leads to the MVP (Minimum Viable Product) much quicker.

If your objective is to create a clean, easy to use product that does exactly what your users want, then YAGNI is your ultimate design pattern. Throw everything out that does not directly contribute to working code. That includes purist build processes and obsessive use of patterns.

Some reading material

You may want to read "Don't make me think" which is an excellent book on user interface design. Also, any of the Gitomer series of books (particularly The Little Green Book) will help you with your sales, networking and marketing skills.


I think a certain amount of interaction design and user experience knowledge is very useful even in a big company for one reason: you as a developer are the first person to actually use the interface, weeks or even months before it is in a usable state for a tester to test.

It can be very useful at the early stages to point out an interface that is not quite as easy to use as was planned, or some design principle that may have been overlooked. Those things can sometimes be difficult to see before you have something concrete to work with, and you are always the first person to have something concrete to work with.

  • I'm not in a big company and I've worked for an interaction design company in the past. I found that because my knowledge was sometimes lacking I'd defer. Do you have any resources or book recommendations? – Rob Stevenson-Leggett Feb 8 '11 at 21:58

I can write a tech spec that will blow your socks off with the amount of patterns I can squeeze in.

That statement alone leads me to believe you need to be working on other aspects of software development.

  • There was an amount of irony in that :) Probably didn't come across too well in the question. – Rob Stevenson-Leggett Feb 8 '11 at 21:57
  • @Rob, glad you said that, I had big red flashing pattern abuse lights going off all over the place. – ocodo Feb 8 '11 at 23:26

While you may never be responsible for every aspect of your company's software, having a wide range of knowledge across a lot of subjects can be extremely valuable. If nothing else, it's more stuff you can drop in an interview, so you can keep your career moving forward.

If you're not getting challenged enough in some areas on your job, start your own project at home to do something that you find interesting. Or get involved with an open source project.


No I don't, its not my job to worry about what I'm building but rather to build it to spec laid out by my client / employer. They already know what they want and its up to my to implement it properly so its maintainable. I will give advice when the chance arises if I can tell that they are not quite sure of the best way to put a feature into the software

Probably at some point I will want to make my own project and worry about what I am building but I think for a while when starting a software development career its important to constantly strive to learn the right way to do things

  • Interesting, you're in the minority. Don't you think that sometimes the other people might be wrong? – Rob Stevenson-Leggett Feb 8 '11 at 21:57

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.