A man is flying in a hot air balloon and realizes he is lost. He reduces height and spots a man down below. He lowers the balloon further and shouts: "Excuse me, can you help me? I promised my friend I would meet him half an hour ago, but I don't know where I am."
The man below says: "Yes. You are in a hot air balloon, hovering approximately 30 feet above this field. You are between 40 and 42 degrees N. latitude, and between 58 and 60 degrees W. longitude."
"You must be an engineer," says the balloonist.
"I am," replies the man. "How did you know?"
"Well," says the balloonist, "everything you have told me is technically correct, but I have no idea what to make of your information, and the fact is I am still lost.
"The man below says, "You must be a manager."
"I am," replies the balloonist, "but how did you know?"
"Well," says the man, "you don't know where you are, or where you are going. You have made a promise which you have no idea how to keep, and you expect me to solve your problem. The fact is you are in the exact same position you were in before we met, but now it is somehow my fault."
--
This is the sentiment that I see in the article.
It reads like someone who is not a software engineer criticizing software engineers because they don't do what he wants. Sure there is a reference to culture and that. But, ultimately, he wants software engineers to care about business and market issues over software issues. He sees the software engineer as an impediment to the problems he is trying to solve rather than someone who tries to contribute through his domain of expertise. This situation is not going to change by using the amateur psychology of not rejecting an engineers ideas when they are starting out. That is insulting and, frankly, the heart of the problem -- that he sees software engineers as children to be led rather than peers who you can collaborate with.
his “team-friendly” interactions were usually sarcastic. He often talked about technical debt, our lack of innovation, and the “stupid” decisions holding us back. An irritating “I told you so” sentiment plagued his comments and feedback.
The easily missed point here is that Jamie, on some level, still cares. The ones this author doesn't recognize are the ones who don't give any outward sign of annoyance, because they genuinely don't care. They'll participate in your "chaos is a process" and roll with your shifting requirements by doing the bare minimum at all times. Maybe they'll throw in some stuff occasionally to wow everyone, usually not. They'll just plug along, keeping their ideas and improvements to themselvse, watching you fail. Because they've seen this all before. Rare is the organization that knows what they want, and have structures in place to effectively build and grow products. I've personally seen it exactly once.
I left the first company where I saw it (I stayed for 6 years and learned more here than everywhere else else combined, despite the other problems) because despite having all of these brilliant people and alignment with front-line managers and other teams and strong process and strong product guidance the company was ruled over by a tyrant in the CEO and CFO. The CFO only cared about the bottom line and the CEO, too, but he cared more about taking full credit for all of our engineering successes. The folks I kept in contact with say not much has changed but that they've brought in some MBA types in the form of senior managers and things have been doing downhill since.
The second time, I came in to the organization and it wasn't great but things worked and we were solving real problems for real people and for some reason it clicked well between the different groups/departments. Then the CEO and board, in their eternal quest to go IPO, disrupted the Engineering upper management chain, and we went through 3 different CTOs in the span of about 16 months. Suffice it to say, the magic was lost. That company is _still trying_ to go IPO, of course, and _still thinks_ they'll achieve it by bringing in different executive management players, last I heard.
I agree! You are coding ideas for people, but somebody needs to translate those ideas into code for them to work, and what might be planned might not be the best or most efficient course of action.
Sometimes it is hubris, such as where management prevents experimentation.
Unlike developers who tend to be experts in the domain, managers tend to be experts at sales and management but not the domain of the product.
Yet they get to value market ideas and their impact.
Moreover, they love to hide this behind anonymous "units" and "divisions" to redirect blame and responsibility.
In the past, such problems were solved by analysts and focus tests using prototypes. But when you work on the cheap, even finished applications are prototypes.
At the heart of it though there is a good point, the culture of a workplace can determine how developers operate. That's it but the full picture is: The culture of a workplace determines how everyone operates.
Managers do not 'set' the culture and drive workers with amateur psychology, although they might like to think they do. Whenever I see the attempts to control how I operate in the workplace, I play along and go back to work... worked out so far.
In saying that I have worked in places with culture that I liked and places with a culture I disliked, my work has always been the same, but my attitude differs.
But how can your attitude be the same if the work you're tasked to produce determines your attitude?
Chicken, meet egg. People usually want agency and most would accept responsibility. When you get ordered around and your input is ignored or objectives abruptly changed, the result is loss of morale. Even techniques to deal with it can and will be perverted.
If the manager / CEO / businessy business person is holistically concerned with the health of the business and the software engineer is only concerned with their domain of expertise, they are relatively childish compared to that person that is expected to know enough about everything and sincerely takes it on.
Depending on how awful the process / culture is you might be right. However, it does go a long way to avoiding that outcome if technical types can juggle a couple business or other concerns outside of their narrow job description.
> His concern for market share and business health is replaced with (...)
> His enthusiasm for changing the world is replaced with nit-picking the development process.
Here's your answer. It's because you hired the programmer based on technical competence and not their attitude to servitude in business.
You get what you measure. You didn't disqualify me as a candidate because I think your business is boring and I need the money. So don't be surprised that I'll be doing my job as effectively as possible - which involves lots of lone coding, unless your internal process is completely bonkers - but I ain't gonna drink the kool-aid. Want someone with a more "professional" attitude? Filter for that during the interview.
And that "changing the world" thing? That's just bullshit, and you're not fooling anyone past their teenage years with that. You're not SpaceX. You're not changing shit. Chances are, you're just trying to make money selling the usual butt CRUD everyone else is selling too. If you hire smart people, don't be surprised they know it's bullshit.
Programmers want to code because they're programmers. Chefs want to cook because they're chefs. That's what they do. This article only shows hiring laziness, coupled with usual complaining that the company isn't getting more than it asked for.
--
EDIT:
Ok, this article doesn't only show hiring laziness. The point about how vulnerable enthusiastic people are in the initial period is spot-on and I agree with it. I wrote the above comment because I believe that the article as a whole exemplifies additional lack of understanding of the perspective of programmers, which can lead to extra post-interview disappointment.
You've missed the context and the point of the article. The author is specifically speaking about employees who are full of ideas at the outset, but withdraw into their shells after a couple months. The problem the author is trying to address, is that of would-be enthusiastic employees becoming disengaged because their ideas are not given a fair-hearing. This really resonated with me, because even as someone who's motivated to make an impact, I've personally experienced it in the past. The points you're making are valid, but completely orthogonal to the article.
I'm not sure if my comment is that orthogonal - the core point of the author may be what you described, but the article exemplifies some pretty pathological issues too.
As for the issue of "would-be enthusiastic employees becoming disengaged because their ideas are not given a fair-hearing", I do agree. This also affects communities, and even interpersonal relationships. There's hardly a better way to destroy someone's willingness to help if you keep hurting them at their most vulnerable period - when they're full of enthusiasm, and trying to contribute their best.
I liked the way you described displaying enthusiasm as a form of vulnerability. I never thought of it that way, but it's very true. It takes courage to openly display enthusiasm, and it's so easy to deflate it by making snarky comments or stonewalling.
Yes. When you share something with someone, or put an effort for someone, out of the depths of your heart, that's when you're vulnerable for rejection or ignoring.
I unfortunately know it from personal experience, from way before I entered the job market. I've always been full of enthusiasm for stuff, but after few unfortunate episodes in my past, I find it hard to share that enthusiasm with people - especially those close to me. I like to think I'm making progress in fixing the damage, but the process is slow.
Maybe I'm wrong, but it seems that you're took phrase out of context and didn't get whole point.
I think good programmers are good because they have good problem solving capabilities, and that's what can be applied to any area.
So, some programmers with good problem solving capabilities just genuinely want to help and fix some problems they see outside of their direct area of responsibility — the code. And when managers are not listening to them, basically thinking 'why you ask questions, you should code', it's quickly becomes obvious that the only way to win is not to play.
I usually am totally in line with your insights, but not today? Perhaps our viewpoints on this issue are colored by our history and current situation.
I for one am on a contract that's exactly as called out in the OP. Been on the job for 2 months (today), and have precisely one line of useful code contributed to the code base. Not for lack of trying; I've written a lot but its all been rejected out of hand for not being 'in process'.
I've responded by putting my head down, shutting up and doing literally what they ask - including moving that line of code between the half-dozen incompatible source bases repeatedly. I've shunned meetings, reduced my email to terse responses, and begun looking for another contract in every free minute.
You have a startup environment where I can move fast and deliver a feature a day? I'm your guy. But make me rebuild a Gb of shabby code over a slow link a dozen times because of thousands of poorly-written 'tests' that fail intermittently, I'm going to back away carefully and bow out.
> Perhaps our viewpoints on this issue are colored by our history and current situation.
Might be.
I'm not disagreeing with the article about how programmers can be completely discouraged by the treatment they (or you here) described. Maybe I shouldn't have jumped straight to ignoring the core point and commenting on everything else that the article said, that I believe exemplifies pathological issues that hurt the culture in the company.
Right; I'm of a similar opinion on that part. Philosophers have always thought we needed a philosopher king; military types want a General for president; businesspeople want a merchant king. Conversely, team leads think everybody on the team should know what they do.
We need a leader that can lead. Can enable the team to progress. Without asking them all to understand the details of the goals (business plan; budget negotiations etc).
It would be strange for a programmer as an employee to care about the business or the product, given that he has to work for a living and has no stake in any of it. It seems to be a common misunderstanding, unicorn employees that want to care about the business don't actually exist, but a lot are willing to lie about it of course.
How do you make something better if you dont give a shit?
It's not only not strange, its pretty much a job requirement to recognize your job is the stake in the business.
Every single programming job I have had has required me to care enough about the product and the business to understand, interpret, and implement things that the business wanted but couldnt fully articulate.
That being said, if the business wants you to be both the business and the programmer, they have a broken system and are failing to manage properly
Having a job is not even close to a "stake in the business". If you want me to act like I have a stake in the business, give me a stake in the business.
To be clear, that's stock with dividends and voting rights. Something like democratic control over the workplace would do wonders for morale. Then managers answer to the body of employees as a whole, not the "boss."
Sounds like you should start a business.
You absolutely have a stake in terms of your paycheck, is it as great a stake as you would like? No.
Are plenty of people happy with that kind of stake? Absolutely.
Do you need to get paid in stock to get paid well? No, in fact in many cases its gambling with market forces you simply cannot control.
I dont mean to say you should burn your life for a business, but if you simply dont care because "I am a programmer and I dont need to" imho your general effectiveness is going to be low, your skill progression isnt going to be fast, and your chance of getting hired somewhere with equity that isnt a shitshow is also low.
You absolutely have a stake in terms of your paycheck [...] Are plenty of people happy with that kind of stake? Absolutely.
That "stake" is a product of how good the employer is relative to others, how hard it is to find another job and the job market for the position in general. I don't begrudge people for being happy with that. I am one of them. But a first order approximation of this "stake" can be summed up as "no stake."
Sounds like you should start a business.
Whether the parent poster should start a business is irrelevant to whether or not it's bullshit to ask/expect employees to be motivated as if they have a larger material stake in the business than they do.
First of all equity doesnt mean stake, you can absolutely trade equity for cash, and your payroll can absolutely be a large stake in the business.
What it does mean is that your stake is not directly 1:1 tied to the business success. This goes back to gambling, if you are the house and take money on every deal, you have a stake in deals continuing to happen.
You are right that your pay is based on many factors, and so would your equity.
So I disagree with your summation, and I think its improper to pretend that equity is the best way to get paid and to care about what you are building (especially when you believe in a product but risk is high.)
To your second point, you can argue (and I think successfully) that having more of a direct stake in a business will increase your personal investment, but that is literally the concept of ownership.
If you think the current practices are bullshit I do believe starting your own highly successful business is the correct approach; you get what you want and if you are successful enough, the industry will change behind you.
I did not say "you should work as if you have a greater investment than you do" during any part of my comments, simply that if you dont care about the product you will not produce quality work.
If someone isnt paying you what you are worth, you are not going to produce quality work.
The point of the stock isn't selling it for cash, it's having a share in the profits and more importantly voting rights at the company level. Are plenty of people "happy" being wage labor? Maybe. Certainly compared to some of the alternatives - unemployment, welfare, homelessness, lack of health care access. Is it really anyone's heart's desire to sell their labor for a paycheck, though?
Start a business... I've thought about it. If only it were so easy. Even if I did, that solves the problem for me, but not anyone else.
Well, you do have to give a shit. But giving a shit about doing a good, honest job, is not the same as believing the business or the product. It's like this saying - one should be able to understand an opinion without believing in it. Similarly, one can put their best, honest effort working on a product while at the same time believing the product is generally pointless and waste of space on the market.
(Of course if one is deeply cynical about a business, one should consider changing jobs - but that's not always easy or possible; in fact, most people are in position where they need the money, whether they actually believe in their employer or not.)
I think its quite hard to do that for a long period though, if you truly dont believe in the product and are only working for the paycheck, apathy is going to set in fairly fast.
If you can find pieces of it you can be proud of and care about, you can maintain sanity.
As a chefs career progresses, they start to want to develop recipes, work out how to cook them effectively and then teach the juniors, develop the menu, pick the ingredients and vendors, and even help with the layout of the restaurant. What they want to do less and less is spend all day chopping and frying.
> You didn't disqualify me as a candidate because I think your business is boring
Er, I suspect this would make it impossible to staff 90% of positions in programming. If I thought a business were exciting, I would be a specialist in that business, not in programming - or I'd be a very lousy 9-to-5 programmer, because my passion lies elsewhere.
Very few companies have the luxury of hiring passionate programmers who are also interested in making the business succeed; most of them just want their payroll system chugging along and someone to sort out their Excel when it breaks.
> Er, I suspect this would make it impossible to staff 90% of positions in programming
Well, of course. So a typical company with a boring business[0] shouldn't expect that people they hire will suddenly develop deep love towards the company and the business it's in.
> Very few companies have the luxury of hiring passionate programmers who are also interested in making the business succeed.
Exactly. Very few companies need that luxury, too. That's why I'm saying this article is an example of complaining about not getting more than one should be getting. When you hire someone to do the job right, you require them to do the job right[1]. Asking them to behave like a co-founder, except without equity and any decisionmaking capability, is a bit much.
--
[0] - I'm not saying "not important". Driving a garbage truck or managing payroll data are examples of jobs that are boring, that don't "change the world" by themselves, but are nonetheless very important - each instance of such a job is a crucial thing for a segment of society that benefits from it directly.
[1] - And in our industry, that does involve letting them run some of the show. When you hire an expensive specialist, you do that because they have the knowledge and experience you don't have (or don't have time to use yourself).
I've worked with programmers who have specialized and stayed in one (non-tech) industry for long periods in their career and they're often behind on the tech and lack the benefit of cross fertilization of ideas from other industries.
That might be the right trade off if the domain knowledge is a lot more valuable than the benefits of the newer tech, but it's still a trade off.
Another great thing about these passionate unicorn programmers is they are passionate about doing stuff for me that they don't ask for very much money to do it. Just need to find some of these people!!! If you are one of them, let me know!!!
> So I am wondering what led to the conclusion that this article blames stuff on the programmer?
I'm seeing the same problem over on Reddit [0], I think that the problem is that the article buries the lede.
The entire first section is consistent with "blaming the programmer", and the title of the next section is "Why are some programmers such jerks?". That's probably where a lot of people just stopped.
The stuff I addressed in my comment is the backdrop of this article, and I understand it as being the implicit expectations of the author. I question the validity of those expectations - I believe they're unreasonable and unfair to the programmers.
The programmer in this story has realised this fundamental truth:
The spoken word is ephemeral and easily forgot. The design of the product that pays the bills is not so easily undone.
What people say in meetings; all the posturing and preening; the petty one-upmanship and power-play — none of this has any relevance to what actually gets done in the real world.
When it comes to what actually gets implemented — all of the power is in the hands of the programmer who gets there first. After all — once the die has been cast and the direction set, who is going to undo the work and start again?
In this, the programmer is the decider.
Programmers have an immense amount of power, and there is no reason whatsoever why he shouldn’t simply ignore the pointless social preening and get on and make the product that he wants to.
After all, the consequences of his decisions will ripple far and wide thorough the product and beyond and have a heft; a level of consequence and a permanence that no ‘soft’ skills specialist can match.
> What people say in meetings; all the posturing and preening; the petty one-upmanship and power-play — none of this has any relevance to what actually gets done in the real world.
That just sounds like you've had very negative experiences in terms of meetings / company culture.
I have lots of meetings where collaboratively we come up with much better approaches to problems, by sharing information and ensuring everybody is aware of other people's perspectives and domain expertise.
Sometimes yes there is confusion and BS. But if we push through it, we usually come out doing better work - or in the ideal case LESS work!
My comment illustrates the situation in a particularly dysfunctional and corrosive organisation.
Whilst none of us want to work in a place like this, and none of us enjoy the experience if and when we are forced to do so; we cannot pretend that workplaces like this do not exist.
Sadly, dysfunction is probably more prevalent than we would like to admit.
Fortunately, we are blessed to live in a world with endless variety; a world in which workplaces with a much healthier and productive culture also exist; places which genuinely foster cooperation and loyalty and encourage and support their employees to contribute and to feel positively about their contribution.
A healthy team is a team with high social capital: a team that seeks the common good, where people clean up after themselves and volunteer to help others. Everyone wants the best idea to prevail. All this while preserving critical thinking and trusting other people with the feedback that is necessary to improve. Their most important competitor is another company.
An unhealthy team is a team with low social capital: a team that seeks individual gain and people force others to pick up after their technical debt. Everyone wants their own idea to prevail. All this while avoiding any form of uneasy conversation and withholding feedback. Their most important competitor is each other.
Absolutely! And I've seen companies with reward structures that focus on individual performance cause a lot of these unhealthy teams to arise unwittingly.
I couldn't agree more, once team members start focusing on personal glory they lose the big picture. From that point onwards team becomes an inefficient machine with sustained decay.
Besides scandox's comment, where do you work that you can actually do that and get away with it? Where I've worked, a programmer who did that might get to decide a few things unilaterally, but not for long.
I'd say 40% of the time of my career I've been in a place where my ideas were valued and I felt like "part of the team" as a programmer, and later as a programmer/manager. Those places I stayed the longest. They make up 15% of the number of companies I've worked for (my résumé has a lot of places on it..ha!).
The rest of the places I was beaten down, much like the programmer in this story. Unlike that developer, though, as soon as I started to feel like the only skill I was valued for was raw programming I started looking for another job.
In my comment I am describing the culture at my former employer -- a culture that led to processes where you had to get your manager's permission to check out a file before you could modify it.
This happens if your superior doesn't critically evaluate anybody's work, and there are no code reviews. So if there's no feedback culture. At my company, my superior sometimes writes emails regarding commits, but since he doesn't write that down (waiting-for list in GTD) I figured that I can simply ignore the emails, and nothing happens. The result is cowboy coding.
My experience with code review is that code reviewer is the one holding the power and refuses to accept code until it does what customer did not wanted.
If you have position without checks, including code reviewing, it will be abused.
This is an unfortunate experience. The best environments I've seen have a core value of respect for others, and code reviews exist to benefit not just the customer but also future programmers (which also ultimately benefits the customer but in more indirect ways, such as reducing cost of change). The absolute best are the ones where the reviewer is giving advice, but can't hold back integration. Much less threatening circumstance. More collaborative.
The best reviews that I have experienced are side-by-side reviews with the author walking the reviewer through the code. The author finds most of the bugs; the role of the reviewer is to force the author to cover all the ground; asking questions where he does not understand something.
> Programmers have an immense amount of power, and there is no reason whatsoever why he shouldn’t simply ignore the pointless social preening and get on and make the product that he wants to.
what
so you're just going to ignore everyone else and build something you think is right, because you're writing the code?
I would most certainly undo your work and fire you, it would be much cheaper than selling all of your assumptions.
That is presuming you are able to find out what is happening -- the dysfunctional situation that I described comes about mainly because everybody is pedalling so hard they don't have time for humane man-management let alone watertight oversight and review.
In a half-way competent organisation the team is able to align to common goals and people can be trusted to work together towards a mutually agreed outcome.
It is when the organisation is run in an aggressively competitive dog-eat-dog manner -- where (for example) a five man team is responsible for its' own profit and loss; where the teams that are perceived as performing well -- that are willing to lie and deceive more aggressively -- are allowed to cannibalise budget and resources from teams that try to maintain some semblance of decency -- where your nationality and race have a bearing on whether you have credibility within the organisation -- where managers scream at each other in the corridors and conspire against each other behind their backs -- and where engineers are threatened with lawsuits should they dare to leave ...
> What people say in meetings; all the posturing and preening; the petty one-upmanship and power-play — none of this has any relevance to what actually gets done in the real world.
So you are saying that you have never seen a solid software system that shouldn't have been built?
> When it comes to what actually gets implemented — all of the power is in the hands of the programmer who gets there first. After all — once the die has been cast and the direction set, who is going to undo the work and start again? In this, the programmer is the decider.
That is how you loose customers. And how software teams get bad reputation and then wonder why-oh-why are other departments so hostile next time they have requirements. And why other departments assume bad intentions on honest bugs - because their experience in the past was exactly that.
Absolutely true ... which is why you have to work very very hard to prevent the rot from setting in in the first place. Setting the right organisational culture is such an important step in avoiding this corrosive and unhealthy situation.
After you have a good decade of experience under your belt, most programming is... easy. Sure maybe not if you're working on self driving cars or game engines or kernel modules, but then the programming is only half the point anyway - the rest is math and science.
But if you're not working on one of those but doing something more typical, and you're decently experienced and competent (and maybe also not compulsively chasing the bleeding edge), then programming is often just cranking out features, a steady drip of success. So of course the path of maximum pleasure is to crank out code.
What's harder than coding? Smartly balancing the stakeholders. Maintaining the discipline, motivation, and knowhow required to maintain the engineering process - testing, documentation, CI, etc. Herding the cats that are a group of programmers, managing the egos, ensuring that a team stays aligned on style and architecture, that's the hard stuff.
> ...for the issues you mention soft skills are a must have...
Only because technical decision making is poorly structured in most organizations. Or it's clear but evaluation of decisions and decision-makers is poor.
If it were:
- get feedback from these N<3 people
- here's how you do that
- they are required to give clear decisions
- within X days
...it wouldn't matter so much that Engineer McCodeface wasn't the best at attending happy hours, back-scratching, etc.
This only works if your organization actually hired at a certain minimum level of competency from EngineerMcCodeface[1..100].
In a hospital interns opinions do not carry the weight of residents, residents opinions do not carry weight of the attendings, and attending opinions do not carry weight of a Chief of Surgery.
- you were a chef. you went to culinary school and know about cooking and best practices.
- you are asked to forget everything you learned in school and flip burgers with overly reused oil and unwashed equipment.
- you are told that there's no time to clean the kitchen, or wash your hands. just flip as many burgers as possible to maximize profit.
- the ones that cook the most burgers are rewarded, treated well, promoted. as soon as cooks realize this, they start making half-cooked burgers that make people sick.
- the customers get sick all the time from the lack of hygiene. you talk about it, and you are told to keep doing what you are doing, or that you don't understand what being a chef is, or what the business is.
- in the end the only source of gratification is getting a paycheck, or doing something in your spare time. you are not cooking real food, just part of a machine that makes money for a self-serving company while ripping off the customer.
This is what it feels to be an engineer in many companies.
>But, two years later, Jamie was “that guy”. You know, the one who wants to code without being bothered.
>I should have noticed the signs. He didn’t speak up in retrospectives, he didn’t contribute process or product ideas like I expected, and his “team-friendly” interactions were usually sarcastic. He often talked about technical debt, our lack of innovation, and the “stupid” decisions holding us back.
I suspect if you just gave Jamie free reign to spend most (not all, just most) of his time refactoring the code base and fixing up the dev tooling while other people worked on bugs and features then Jamie would be happier, the code base would be less buggy and the other developers would get their features done quicker.
The fact that Jamie is quite grumpy about all of this suggests that the code quality and tooling at this company is poor and he isn't being allowed to fix the things that are causing him pain.
And maybe he doesn't want to meet customers? Is it so bad if that task is left to somebody who likes doing it?
>His enthusiasm for changing the world is replaced with nit-picking the development process.
>Worse of all, though, his concern that “We aren’t building the right thing” will be replaced with “We aren’t building the thing right.”
This attitude absolutely floors me. You absolutely want a diversity of attitudes and skills on any team and that includes having some people who worry more about building the right thing and other people who worry more about building the thing right. Those are complementary attitudes that usually go with complementary skillsets.
A poignant point -- though I would replace skillset with talent (Gallup's definition: "naturally recurring patterns of thought, feeling, or behavior that can be productively applied"). See: http://strengths.gallup.com/help/general/125543/difference-t...
You said something that reach me so much: "tooling".
I sometime feels like if you don't have good tools, it's almost impossible for the employees to be productive or motivated.
I often see some people working in the most unproductive way possible (to my eyes) that it actually discourage me. I'm left wondering how they can even get anything done when spending so much time doing simple tasks.
Yeah, I sometimes joke that the average developer is a somebody who pushes their code with a series of repetitive git commands typed in unreliably, deploys unreliably with a repetitive set of shell commands, relies almost totally on a battery of bored, robotically clicking manual testers and believes that he is automating people out of a job.
I think one of the most underrated (and almost totally ignored) parts of the mythical man month was the notion of the toolsmith being a dedicated member of a good software team who doesn't work on features.
"Culture isn’t the slogan on your wall, or how you describe your mission during an interview. Culture is the way people actually act, and what they actually care about."
PMs and Dev Managers, your engineers are smart, dynamic individuals. If you engage them and include them in important conversations and actively solicit their feedback while providing context and customer feedback, you will get innovative and creative ideas, you will get an energized work force, and everybody will be happier for it. Don't treat engineers like an assembly line: software is a dynamic machine and it requires everyone's best work to evolve in the right way.
While you're not wrong about culture is action, here's studies show collecting and disseminating that culture (aka writing it on the wall - knowledge management in the literature) leads to measurable competitive advantage.
3 years ago I crossed the ocean to join a team on a project that seemed great.
I'm not 25 anymore so it was a big deal, moving my wife and kids (but it's on a Caribbean island, so they were not hard to convince).
I was asked to join because of my background in mathematics, my vision on resolving problems, and my programming skills.
Not bragging, I'm just a regular guy, but the person recruiting me was the co founder of my company, we know each other for 25 years. So he knows me well and know my skills. I was asked to join for bringing a new vision on some tricky points.
Small team, one leader.
Almost every time I proposed something new, it was dismissed, and sometimes with contempt.
Of course it's something they worked on for several years, and they tried a lot of solutions before I joined, so some of my idea were surely already tested and all.
But I ended up doing some UI on jquery (yeah, I know...) and became miserable as time passed.
Because, you know, before even be sure that the core was working, they wanted a fancy interface...
Ended bad. I finally quit after 18 months of doing the same stuff again and again, as the UI changed every time a new idea came up.
My point is I totally understand the point of the article. I came with a bag full of ideas and happiness on working on that. I ended doing shitty stuff and feeling uninterested and bored about programming shit all day.
I cannot count the number of times per that one of the following situations has happened:
- I go to our designers with an inconsistency, omission or even an outright contradiction in the design just to hear that this is how it was designed and that the client approved this design, so we should implement it precisely as the design says.
- Development is slowed down/held back by technical debt and odd implementation choices. When I suggest we fix this, I get told that fixing what isn't broken doesn't earn us money, so I should work around it for now.
- I have a suggestion for some process improvement (for example: developer post-mortems, including developers in the design review process), to get told that it's already been tried at some point in the past (usually back in the really early days of the company when there were less than 5 employees) and that it didn't work back then, which means that it will never work, no matter how much has changed since then.
> including developers in the design review process
I was banging this drum for 2 years at my previous employer. I was always told it's a great idea but the people who knew projects were coming down the line just never reached out to the tech team.
We are all tech consumers, letting the design team work exclusively with the client is a great way to build the wrong product/features or over/underestimate the art of the possible.
> letting the design team work exclusively with the client is a great way to build the wrong product/features or over/underestimate the art of the possible.
Pretty much this. We consistently get screwed over on our schedules because designers just throw a design over our way without asking us for any input along the way.
"It’s only natural, then, that your programmer is reduced to doing only what brings him success: coding."
Replacing "success" by "pleasure" quickly reveals why there's not a single sentence in that article I can agree with. I for one am quite happy not being included in matters that sound like a different job title to me...
I spent most of my day coding. Except for some fresh air breaks and occasional discussions on how to collaborate I actually spend every second doing it. And I love it. The article suggests in its whole premise that this is wrong. For me and for the business. Yet it lacks any evidence on why I should want to do more than that - in fact I would even call it blindly dogmatic in that regard.
But at least in my work context I think that my boss's job is to keep me from customers and design decisions as much as possible - since that is what I love and what yields the most productive use of my time. I wonder why my joiner friends aren't told that spending all day in their workshop creating beautiful wooden art is wrong and that they should instead derive more pleasure from interactions with their customers...
Maybe in an ideal world someone who cries over every line of code since she/he would much rather make design decisions but is left out of the creativity loop just isn't a natural coder. Just like someone who hates working with wood maybe shouldn't.
I am well aware that this is a position of extremes and blocks out the gray areas that are reality. But my work reality is just not what this "Hacker, Problem Solver, Calvinist, Geek" regards as the very premise of his manager lesson.
Let me know where I can find a company like this! It’s obvious to me that engineering quality is precisely what engineers should be worried about — the “how” as opposed to the “what” or the “why”. Like chefs should be focused on the food.
When you take the responsibility for building the right thing for the market, etc and smear it across all the engineers, some will step up and become informal managers, organically acquiring power in response to the responsibility put on them, while
others who are too busy programming or not interested in taking on other jobs will realize they have responsibility that is out of line with their power.
> We could all just sit at home and write code all day. but without users there is no point.
Depends on how you are motivated. Speaking for myself, my motivation always comes from myself, never from what others think of my work. The users/paying customers aren't the point, at best they are an enabler, allowing me to spend more time coding that I would otherwise have to waste by having a non-coding job.
I do totally understand that motivation, coding is enjoyable. I have lots of code on github that I wrote that no-one has ever run since the time I checked it in once it worked.
But the PHP code I wrote that was getting 1m pageviews a month gave more of a sense of achievement than my clever raytracer.
I just realized that I turned into Jamie sometimes as well.
At the beginning of a project, I worked without respect to boundaries. When a bug in another teams codebase held me back, I fixed it there. Over time I learned that this was neither appreciated nor welcome for some, so I stopped doing it. Unfortunately, this also a problem for me, because the bugs don't get fixed and block me.
I invited a programmer from another team into my repo and we collaborated there. Then I was told not to do the work for another team (by the other team, ironically), so we forked. Now the repos have diverged and the users, who want to use both, suffer.
"He often talked about technical debt, our lack of innovation, and the “stupid” decisions holding us back. An irritating “I told you so” sentiment plagued his comments and feedback." I recognise myself very much in this traits. When I work on a new project, I maintain a diary with a section todo and a section technical debt. It appears, there are always many items in technical debt.
The mindset of people is very influenced by their role. A developer is mainly fixing bugs and creating architecture that should be less bug prone. Anticipating problems is our job and does not mean we are negative. We are happy when the technical debt is small. I think that this article shows that people have difficulties to listen to developers and do not grasp their mindset. I am quite happy my boss listen to me. In a previous job, I had a colleague who helped me a lot to get listened to.
I think a developer needs to have good stretches of time undisturbed to get work done, but needs to spend time discussing with others to understand their needs and provide his insights. If nobody listen, the developer can only complain like in this article.
I agree. I imagine the beginning of the end is, the agile standup/sprint process. Instead of addressing the code as a whole, we're reduced to picking at one piece at a time in isolation. No development without a customer issue to justify it! Especially the new guy.
And to come in after a couple of years of this, and find a code base that is a pile of individual pieces in a loose spaghetti wad, is so absolutely disillusioning. You want to fix it; you know what needs to be done; but you have to add this field to this structure so some UI element can report some crap that hardly anybody cares about instead.
Just realized this is now me. "A pile of individual pieces in a loose spaghetti wad" exactly describes what I've been made responsible for. Each source file shows scars of sprints where some poor fool was given a story and told "just make it work" with no concern for any big picture.
There is a huge amount of insight on this post and I could not upvote this story enough. It is exactly the onboarding process and all the BS/political powerplay and non-productive rhetorics that pass that exact message to a programmer. Multiply this by ten if you happen to be a non-native developer in a mostly ethnic company where your language skills are below native. So -even though it is never clearly said in the open- the message gets to be 'you are just a "foreign" code monkey'.
Wow. This article really resonated with me. I was "Jamie" until 2 months ago.
I choose my jobs very carefully. So when this company had a reputation of hiring the best, I was beyond excited. The interview process was great. I really liked interacting with the (future) manager.
And....things went downhill in the very first month. In the first team meeting VP announced that the manager was moving on. All the while I could see it was not mutual agreement between the manager and VP. But, I thought that was not my problem.
A meeting was set with the new manager and there it dawned to me that I was in huge trouble. The new guy wanted me to do a presentation in front of the VP and other C-level executives. "But I am not aware of the project requirements" I said. He summarily ignored my objections.
On landing in front of the VP and C-level people I was criticised for not knowing the project requirements. While the old manager tried to help me, the new guy kept his mouth shut.
Later the new manager offered me a half ass apology. That proved to be the last straw and I became the person who just wanted to code.
> Worse of all, though, his concern that “We aren’t building the right thing” will be replaced with “We aren’t building the thing right.”
Oh man, this one hits very close to home.
I can say there exists at least one additional circle of hell, found after the engineer has abandoned all hope of influencing code-quality. The kind found after executives have hired outsourced teams to "help" add features with no code-review process or commit-hooks.
As someone who has been programmer and now hires lots of programmers, there are things in life you can't buy, like love, or in this case, respect.
I learned motorola assembler, then intel's when I was a kid and have been programming all my life,studied engineering and made a software company from scratch.
Programmers respect me in a way they do not respect an MBA, no matter the title or the money they have. In a company it is a big problem.
You can't see it, it is invisible but man you could sense it, it is a very strong force.
This article comes to entirely the wrong conclusion, and I am very encouraged at the number of commenters pointing it out.
Engineers engineer. They are highly trained professionals who are doing their job when they are figuring out how to build something, improve something, or fix something, often with the goal of being able to develop new features quickly without an inordinate number of bugs.
Your engineering team shouldn’t be running your business. Even if they have good ideas. And in practice, they will be overruled immediately, anyway, the moment someone with any real authority makes a roadmap or a key decision, because they are engineers. They aren’t answerable to the board. They haven’t studied the market and competitive landscape in depth. They can’t pivot the company.
There’s something perverse and The Office-like about diagnosing Jamie as a problem “but it’s not his fault.”
Engineer runs into boss’s office: “Sir, code quality is critically low. I suggest we begin paying down technical debt before it’s too late.” Boss, smiling to camera: “This is Jamie. When he started, he was a team player. He believed in the vision. He didn’t spend all day nit-picking about things like code quality. Look at him now! I don’t blame Jamie, though. I blame myself. If I had made Jamie feel like his big ideas and product insights were welcome here, early on, he wouldn’t have devolved into seeing himself as a mere code monkey.”
Yet another person who I feel I would dislike working with. Maybe, at the start of each post where people ramble in such a binary fashion, they could post a snippet of why they think they can comment with authority on whatever the article content is about.
This guys MO ties in nicely with most "well meaning" but utterly clueless folk I've seen when it comes to software development.
I think managers begin to BS around and only caring about paychecks for similar reasons. It's not only the lowest level in companies (programmers, engineers...) who grow tired of non cooperating higher ups.
So there are two stages here... First is caring about the what, and getting no traction in determining that. It's left to the PMs. Second is caring about the how, trying to at least get ideas implemented on that front. But what's the stage after that? If you get no traction on making a better what, nor doing it with a better how?
Will a company with a strong why, a sense of purpose, that is felt and understood by all the employees help ward off the troubles of obsessing over what and how?
Unfortunately I feel like I can answer this (or at least suggest a direction) from current personal experience.
When the engineers are not allowed to fix fundamental problems, the next stage is about defending themselves from blame that they feel is not rightfully theirs.
Ex: _________
"Hi Bob, this problem appears to be due to corrupt data. Our 9-year old platform does not actually use foreign-keys or database transactions, and we haven't been able to get approval to replace it."
"Alex, I haven't seen this feature before, it seems to be from the offshore contractors and their PM. Reproducing the error, it seems they introduced it about five months ago, so we'll have to check those records for mistakes."
"Mary, I'm afraid our software isn't able to support names in those languages. I'm including a link to a memo I made three years ago that explains the limitations and suggests some ways we could fix it, if the business considers it a priority."
> Worse of all, though, his concern that “We aren’t building the right thing” will be replaced with “We aren’t building the thing right.”
To be fair, part of an engineer's job is to give her opinion on when you're not building the right thing because you're building the right thing in the wrong way.
Building something with 10-100X more cost, unacceptable bug rates, or a pivot-unfriendly design means losing money in many (most?) contexts.
It can always be debugged in the next sprint! Just pick up another item from the board and keep coding; if we get behind we'll just hire some more college grads.
Until the code base becomes so intractable, such a dinosaur of brittle features and run-on code that nothing significant can be done without exhaustive debugging. Then no group is large enough to make good progress.
Loose wads of code with random dependencies make the effort grow geometrically. No growth in team membership can keep up with that for long. The only solution is to tightly control dependencies, write good abstractions and keep to them religiously, etc.
So many, many projects head off this particular cliff. They pretend to have life for a while, reducing the feature set in each drop to smaller and smaller items. Relabelling a bug fix a feature, and features overrun the sprint/release and get relabeled 'bugs' so you can keep developing through the test and release phases.
So many of us recognize the syndrome. But so little gets done about it, especially in large companies.
> Until the code base becomes so intractable, such a dinosaur of brittle features and run-on code that nothing significant can be done without exhaustive debugging.
Yes. And that gets at the point of OP. "Let me replace subsystem A so we can free up B resources per year" is a big, if it works. To throw it on the backlog for "when we get time" is self destructive in the long run.
I don't think the author wants programmers to "do" anything. Instead, they want managers to allow programmers to bring their whole selves to their jobs. That means not blockading their ideas from being implemented, regardless of what realm they belong in. If a programmer has a product idea, they should have a chance to prove it's a good one. If they have a process idea, it should be considered. And so on...
TL;DR: I lived this situation on a shitty firm. It's depressing. But "good" firms do exist, don't lose hope!
I lived this situation : I got hired as a developer and got involved into making the product better and improving our processes. But the firm was (and still is) utter shit. It was painful and I was unhappy.
Some people there are still trying to do a good job and they have had several episodes of burn-out. Some other just lowered their standard and accept to get paid to poop some ugly code and apply useless processes (some might be happy, but most of them are dead inside). I just gave up on this nonsense and quit, and was lucky enough to find a much better place. My new firm (not that "new", it's been more than a year now) is not perfect and can definitely be improved... But motivation and commitment into improving things are actually welcome, and it works!
Some of these responses speak to the difference between "programming" and "software engineering". If you want people to hack code without regard for what it is for, you get programmers. If you want a team that is fully engaged in building a product (which means the whole life cycle from requirements to deployment) you need software engineers. If you disempower developers from that kind of decision making, it doesn't matter what their title is.
It's not just programming; anything where your thoughts and concerns are automatically dismissed and shoved aside becomes incredibly demoralizing. Eventually you either give up completely, or you settle into the tiny corner where you're allowed to have opinions and act on them.
The man below says: "Yes. You are in a hot air balloon, hovering approximately 30 feet above this field. You are between 40 and 42 degrees N. latitude, and between 58 and 60 degrees W. longitude."
"You must be an engineer," says the balloonist.
"I am," replies the man. "How did you know?"
"Well," says the balloonist, "everything you have told me is technically correct, but I have no idea what to make of your information, and the fact is I am still lost.
"The man below says, "You must be a manager."
"I am," replies the balloonist, "but how did you know?"
"Well," says the man, "you don't know where you are, or where you are going. You have made a promise which you have no idea how to keep, and you expect me to solve your problem. The fact is you are in the exact same position you were in before we met, but now it is somehow my fault."
--
This is the sentiment that I see in the article.
It reads like someone who is not a software engineer criticizing software engineers because they don't do what he wants. Sure there is a reference to culture and that. But, ultimately, he wants software engineers to care about business and market issues over software issues. He sees the software engineer as an impediment to the problems he is trying to solve rather than someone who tries to contribute through his domain of expertise. This situation is not going to change by using the amateur psychology of not rejecting an engineers ideas when they are starting out. That is insulting and, frankly, the heart of the problem -- that he sees software engineers as children to be led rather than peers who you can collaborate with.