It is easy for managers and customers to appreciate what they can see.

I have seen many GUI developers who are average programmers with minimal knowledge of design principles or other programming idioms. However, these shortcomings often go unnoticed, specially by management and customers, if the programmer can create an impressive looking user interface. So much so that many GUI developers I know spend hours beautifying the GUI at the expense of writing bad, unmaintainable code.

On the other hand, middle tier programmers who develop APIs or business functionality or database code (SQLs etc.) are at a disadvantage as there is nothing tangible to showcase. Perhaps a code reviewer or an architect may appreciate the elegance, good design, scalability etc. of code but it means nothing to the outside world. Your code may run for years without breaking, may be very easy to maintain and have good performance, yet it never elicits the 'wow' that a slick looking GUI does.

In my opinion, a corollary to this is (and I am going to get heavily downvoted for this, I know) that there is less motivation for a GUI programmer to write good clean code.

EDIT: I must explain here that by GUI programmer, I don't mean a full-fledged web/GUI designer but a front-end programmer e.g., a java-swing programmer.

Does the rest of the community agree ?

  • 6
    Who has to suffer through the 'silly' user requests for fonts, labels, colors and moving everything around? You take the good with the bad.
    – JeffO
    Commented Apr 16, 2011 at 22:01
  • @Jeff O: Very true. No user has ever criticized my choice of how much memory to allocate for a data structure or which columns of a database table to index.
    – dan04
    Commented Apr 16, 2011 at 22:26
  • 2
    Having to work with layouts (whether Swing, GWT, HTML, CSS.) is such a torture that not having to deal with it is an advantage...
    – Uri
    Commented Apr 17, 2011 at 2:51
  • @dan04: Try working with senior scientific users. They're happy to use ugly UIs and will spend ages fighting over database structures (usually in an attempt to keep some old unindexable cruft because their old scripts make use of it). Grr… Commented Jul 27, 2011 at 8:32
  • Bit like the difference between a bassist and the rest of a band. They do a lot of import work in the background but no one notices except other bassists.
    – Gordon
    Commented Feb 3, 2012 at 9:13

12 Answers 12


I think I see your point, but I suspect that there is also an opposite issue to consider.

Essentially, I believe you are suggesting that, because the UI is the element of the application 'in the face' of the end users, the UI developers enjoy a higher visibility than the team members working in deeper layers of the app.

Certainly I agree that there may be a higher visibility. For instance, developers working on the UI elements may get to interact with the end users more often (arguably, for good reasons, since they do focus on the Human/Computer Interaction aspect).

Yet, I think that the higher visibility comes in play even in cases when there is a problem. For instance, end users are very likely to report issues as 'GUI Issues' even when they are not.

It may all boil down to perception, and a mature organization should be able to recognize values, virtues and weaknesses of the various team members independently from which layer of the app they work on. A mature organization may also have moved beyond distinctions like 'UI developer' and 'business layer developer', recognizing they are all team members anyway, with different expertise perhaps, but always trying to educate each other on those areas of expertise.

  • 1
    And it's not like most companies take a user survey to see who is the best programmer.
    – JeffO
    Commented Apr 19, 2011 at 11:17
  • 1
    +1. I work on the GUI, and whenever there's a 'problem', it lands in my inbox. The onus is then on me to 'prove' that the source of the problem comes from lower down. GUI programmers also have to juggle the 'purity' of those beautiful APIs with the chaos of user requirements.
    – Benjol
    Commented Jul 27, 2011 at 7:26

For a person who doesn't deal with programmers any, I can confidently say that they would believe this kind of stuff. They don't know the amount of work that goes in the background, all they see is a bunch of buttons/textboxes/menus/[insert GUI element] and the speed it takes to accomplish what the button started. So initially, GUI people are liked more.

If the person does deal with programmers, then its a bit different. As you said they would notice if you made it scalable, easier to maintain, rewrote an algorithm so it made more sense, or any other maintenance type task. This kind of person would look at all programmers equally.

In the middle it depends on what your doing. Speed then becomes the important factor here. If you can show before and after recordings of how long it takes for a form to be processed and stored and there's an improvement, you are equal. If you can show the app under load from 100 clients and show them the server melting, and then show them your version where everything is fine, your equal. Etc.

In short, it depends on the person and what your doing.

  • 8
    As someone who's just spent the last 5 years or so working on infrastructure stuff (SIP stacks), +1 - most people don't know what you're doing, and there's nothing particularly visible, other than something not working. How much do you think about your plumbing... until it breaks? Commented Oct 12, 2010 at 8:11

As the "UI expert" at my company (the guy in charge of all the UI development, not just the design), I think you might be missing some part of the story. While I'm the guy in charge of the UI, I also work the on back-end, on the databases, etc. I do it all (we're a small team). [C# and ASP.Net WebForms development]

First of all, yes it is much easier for non-technical people to appreciate the work of a GUI developer because that's what's in the face of people. To non-technical people, the GUI is the application. The drawback is that the GUI is also the first one to be blamed when something goes wrong.

Second of all, developing the front-end has been much more challenging for me than the back-end ever was (obscure/complex algorithms aside). There's so much more to guard against, it's stateless (our apps are on the Web), browsers don't behave consistently (JavaScript libraries were a godsend), etc. I'm hoping most of this complexity is due to the framework I have to work with (ASP.Net WebForms) and that all the difficult stuff won't be an issue in the future.

Overall, I've had much more difficulty solving UI issues than back-end issues.


I hate GUI development for two reasons,

  1. I am more logical than graphically artistic and my UI always suffers as a result.
  2. As UI isn't based on logic, unit tests are nigh on impossible to write with any meaning

At the end of the day, however, I think that my code will be better appreciated by the end user (as opposed, perhaps to a project sponsor), than that of a mediocre developer who is a whiz at UI, as it generally works.


To (maybe) expand a little on @TheLQ's answer, I think it also depends on the "viewer".

I've had some experience with a few upper level managers/supervisors that don't have a programming background. Some appreciate that they don't program, but understand that chrome and hubcaps are just as important as the engine and chassis.

And I've had experience with some upper level managers/supervisors that don't care about any metrics other than the UI sizzle. Even stating that more UI oriented developers where important.

IMHO, we all know that you can't polish a turd and a fast, reliable yet ugly app will far worse than an app that both looks good and functions good. It's all in the eye of beholder and to an extent, you have the power (regardless of what you do) to be seen in the light you want, by working for those that appreciate the same qualities as you.

EDIT: I might add, being someone who feels more comfortable working on lower-level items, I have been jaded when you work equally as hard as the UI team and it's the polish that's lauded in the demo and not the fact that the system "just worked". But like I said, I know that my supervisor's know the work is needed on all areas.


I think there is a general presumption out there that the UI developers are the "junior" developers. I can only think of one case I ran into where a UI guy was considered senior.

That said, I think UI is a lot harder than any other part of our apps. And I'm not talking about the UX design, I'm talking about the coding. How many other areas do we code in where we have to account for dozens, if not hundreds, or possible scenarios? Just resizing a screen can sometimes become a royal pain when you need to figure out what needs to happen with a couple of dozen elements. This primarily comes up when you have guidelines that say "we need to support 800x600" and then UX designers that never use anything other than HD resolutions.

So, if they get more goodness because of more exposure, they probably deserve it. Usually, they are on the wrong receiving end more often than the good receiving end.


There often seems to be the idea that a GUI programmer is at the bottom of the programmers chain. How hard can it be to drag & drop a button in VS to a form? What, it will take you a week to program that? It's drawing some bars. So I'm not surprised to see the idea that GUI programmers, being the button draggers as they are, must be writing horrible code too.

GUI programming does have some unique challenges. Multithreading to keep the GUI active while the data loads. This leads to thread safe and proper code. Performance is very important. Noone likes to wait two minutes until they get control of the application again. Re-usability also becomes a big issue. If you have to write ten similar screens you'd better structure your code well. This leads to better code. And of course creating a good GUI is a challenge in itself.

But to some people it will just be dragging a button to your app. Just as for some people the business logic is nothing more than "parse a message and put it in the DB".


I think it's obvious that they do. Perhaps top-notch dev houses are exempt, but most others aren't.

When your manager asks you what you have done over the last month, it's easy to show a cool GUI. It's hard to show a cool API. Very hard. API coolness is only apparent through actual use - it can't be appreciated at a glance.


You can get away with all sorts of hackery and shortcuts in the internal systems. When dealing with the GUI you do not have that freedom. Your internal api may have inconsistency and you just expect the coders to deal with it because its too hard to fix. You cannot trying and make your customers do the same thing. So in some sense, the people who have to deal with the user visible components have to actually follow a higher standard.


I'm going to say yes, for one simple reason: The iPhone. Everyone I've ever spoken to thinks it's fantastic because of the slick interface, but I can only imagine the work underneath to make that all possible.


It depends on the audience. I work with a lot of financial analysts and their idea of a good gui design is one that has as many fields as you can possibly jam onto one form. Seriously, I'm talking 75 - 100. They're data junkies who always want more. I recently improved the performance on a few stored procedures that could take 45 seconds to load (calculate weighted averages since the beginning of time stuff). Got it down to 30 seconds; I'm thinking wow, cut one-third of the time; it should be a line item on my resume. No one even noticed. Kept working on it and got it to 15-20. Noticable change. Everyone was very happy. I still think the GUI is an abomination and if we took out this useless crap, it would load in 2 seconds, but when there are 15 different multi-line text boxes (You know the ones that have all the formating capability with MAX character settings.), it's hopeless.

So if you want users to really love you, remember that the best user interface is no interface at all (wish I remembered who said that). After wanting to see all these data, my analysts have realized they are the ones to do all the data entry - the horror.


Testing UI parts of the application is a nightmare.

Every person around feel competent to give an advice or to set a demand how you should do it.

After the system works OK, later even if somebody maybe accidently recalls who hes the virtue in it, nobody will remember who did what.

But if any error will be seen (some always happen), the first man to be convicted will be the GUI programmer, The user simply never had seen the others!

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

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