Take the 2-minute tour ×
Programmers Stack Exchange is a question and answer site for professional programmers interested in conceptual questions about software development. It's 100% free, no registration required.

I cannot believe what just happened. I'm an expensive full stack developer, although I have focussed on WPF and Silverlight lately.

Much of the time, I write Controls, ViewModels, Repositories and a bunch of asynch code.

This contract I'm working today is a shambles. The code is a mess. Everything is tightly-coupled, no MVVM, and a bunch of stuff ripped from CodeProject.

I taught a junior guy how work the Parts and States model, build Controls and VMs and be a great UI dev. He tells my boss that he's formalising some new feature into a control and my boss says "We're not in the business of building controls."

While their sole product is a WPF client, he could not be more wrong. He just wants crap smashed out my juniors in a hurry.

What would you do in this situation? How would you explain it on your CV/resumé?

share|improve this question

closed as not a real question by Rachel, Walter, ChrisF Oct 5 '11 at 13:05

It's difficult to tell what is being asked here. This question is ambiguous, vague, incomplete, overly broad, or rhetorical and cannot be reasonably answered in its current form. For help clarifying this question so that it can be reopened, visit the help center.If this question can be reworded to fit the rules in the help center, please edit the question.

Does your boss know what a 'control' is? It seems like a very ignorant statement to make. –  Kirk Broadhurst Oct 5 '11 at 11:25
It sounds in your case that this is merely a mis-communication issue. So while it may be worth correcting the managers misapreciation of the situation, consider that unless you are someone like Telerik or Infragistics then you aren't in the business of building controls. What you are in the business of is producing the client that enables your customers to do XXX. If you building controls is the best way to do that then all good, but realise from the business' perspective buying an equivalent control could be better. –  CdMnky Oct 5 '11 at 11:58
Sadly, he knows what controls are. It's like upon hearing an engineer saying that he'll be spending his time welding the chassis together, the CEO of Ford saying "We're not in the business of welding." Consequently, the company I'm at have a car that's nailed together. –  Luke Puplett Oct 6 '11 at 20:30

4 Answers 4

Your junior might have just picked some bad terms to use when talking with your boss, so your boss is probably thinking his jr is building a control library, like telerik or infragistics.

Explain to him that is not the case. Tell him you have the junior guy working on the interface, and that you're building it in such a way that you can re-use the pieces in other pages/forms to make future development faster.

If he's unreasonable, well you still can put down that job as WPF/Silverlight experience that included mentoring/teaching other developers

share|improve this answer
+1, about resume experience and NOT renewing the contract with them. When I was asked about a similar experience and why I left so early, I eloquently put it that, "I came in to help them find solutions to development challenges, however they have already determined the path they wished to take development. Since they have already made up their mind I couldn't help them and decided it was best to part ways." –  maple_shaft Oct 5 '11 at 11:44

Your mistake is that you used inappropriate terminology when communicating the status of your juniors to an extremely non-technical manager.

A non-technical manager listens to the words "developing a control" but what they hear is "spending weeks writing a custom time picker when a third-party control set time picker has 98% of what we need."

Certainly this is not the case in WPF but to somebody who maybe has a basic understanding of VB 6.0 this is what a control represents.

It is better to state, "the junior is working on a resusable and configurable component to meet X number of features in less time than was scheduled."

share|improve this answer

Typical problem with managers. They only care about final product (in the sense that it must come to existence at a precise date) and not really care what is under the hood. In my personal opinion the best way to get some technical fact to manager is to use proper analogy. Something like this:

If your business is producing milk, you need cows

...and then simply state that it's the same way with your company:

If your business is producing WPF apps, you need controls

That's just gross oversimplification, but I think you'd get the point. Just watch out when coining your analogy or you will get into trouble (of course, the real danger is when somebody proves your analogy is wrong).

If this fails, then let junior do whatever he is forced to. This is very sad, but the best way to solve programming problems is to convert them into management problems. I was working pretty much with the same stuff. Management was forcing dirty hacks up until it took a week or so to perform trival change. They tried hiring somebody "better and faster", but everybody replied with "No, I dont wan't to be swamped fixing this mess, thank you very much". Then they started listening to what we had to say about development process.

share|improve this answer
Again, thanks for your time and answer. It seems to be an endemic problem with the industry, compounded by the trend that the best programmers tend not to enter managerial positions. –  Luke Puplett Oct 5 '11 at 11:18
@LukePuplett, The other way around is even worse though. When all the best programmers become managers then the only people writing code are nimwits and window lickers and software quality plummets. –  maple_shaft Oct 5 '11 at 11:28
@maple_shaft I can't decide if I'd rather have a bad programming team that I have to baby-sit, or if I'd rather have a bad boss that doesn't know how to handle the project.... –  Rachel Oct 5 '11 at 11:34
@Rachel, If the bad boss is a micro-managing sociopath then I would rather have the useless developers. If the bad boss is out playing golf and graciously allows you to do his day to day job then I would rather have the bad boss. :) –  maple_shaft Oct 5 '11 at 11:49
@Rachel: You seem to assume that a good programmer is automatically a good manager... –  nikie Oct 5 '11 at 11:51

First thing first, take a deep breath. Try to come up with a short and constructive answer to the problem. Be assertive and not aggressive. Explain why controls will reduce costs, increase profitability, and make the code future proof. Try to find out why the manager thinks what he thinks. Maybe there is a fundamental miscommunication there. Ken Back's Assertiveness at Work: A Practical Guide to Handling Awkward Situations is a good read for just those kind of situations.

But if all of that fails, say "thank you for your time" and leave. On your CV, put it down as dealing with unreasonable people (read: people skill).

share|improve this answer
Thank you for you answer. Had to go for a walk around the block :-/ –  Luke Puplett Oct 5 '11 at 10:06

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