Having done this stuff for about 15 years now, it is amazing how much of your work is scrapped in 5 years or less.
If you're writing some deep enterprise level back-end stuff that is going to be integrated in a large, expensive system, obviously it really is worthwhile to do it right.
If you're cranking out another piece of shit marketing website, or even better, anything app or mobile related, no matter how much planning and testing and pride you put in to it, it is almost always completely worthless in a couple years.
Everything is changing so fast right now, the platform, device, language, database, etc, may not even exist in 5 years. 5 years! That's a hell of a depreciation schedule for a $200k project.
This resonates so much with me... i really dislike the way how much my work is depreciated after just months...
I really learned not to invest much time and finesse into those kinds of projects. When i was younger i was thinking "oh, someone may look at the code, keep it clean...".
Nearly 10 Years later and dozens of projects later: Only 5% of my code ever got even a second glance or had to be changed...
It's a self-fulfilling prophecy. Technology management has given up on the idea that code can actually be read, so it's write-once. Reading Code is that ghetto where you put untalented people you want to fire, or young/new people you don't know what to do with yet. Otherwise, the idea that people can actually read code has been given up on. That, of course, generates a class of programmers who never improve and write terrible (illegible) code.
If your attitude is that reading code is a lost cause, you'll create a bunch of shitty, illegible code.
People forget that outside of the corporate world, there actually is code that people (a) enjoy reading, and (b) write with the intention of making it comprehensible.
Also, "doing it right" is an illusionary dream when your software interacts with the real world. In my opinion, it is not true that most code complexity comes from being lazy about code structure and simply not caring whether "models know about my views or not". This might happen sometimes but is usually easy to fix. It makes up a small percentage of code complexity.
There is an impedance mismatch between the way computers work and the way the real world works.
Software works in clear conditionals, numbers without any uncertainties, events that flow deterministically based on relatively simple rules.
The real world works in probabilities, half truths, imprecise numbers, special cases, partial information, irrational actors and deliberate rule breakers.
When you start writing a new piece of software, at first you tackle the most common cases of the real world. At this point it is possible to write clean code and well defined abstractions. However, eventually you are going to get users that will find that your software is too simplistic and doesn't take into account common sense exceptions, doesn't give them enough flexibility to deal with partial information and doesn't allow them to act according to unwritten exceptions to the rules. You have two choices. Either refuse to bend your software to the real world to keep code simplicity or start coding in the exceptions that your users desperately want.
Computers don't understand common sense so you have to translate all these exceptions into well defined rules and heuristics even though this does not reflect how things work in reality. Because computers don't think probabilistically, these heuristic tend to be numerous and complexe and difficult to deal with.
The main jobs of programmers in my opinion, is to manage this complexity so that their programs don't become too unpredictable when the thousands of exceptions interact together in unexpected ways. It's quite the balancing act but I think the best developers are those that don't back down and are able to face these types of problems. Sometimes this means refactoring some exceptions out of the system, or moving it somewhere where it doesn't cause unwanted interactions but sometimes it means leaving it in and managing it as best as you can so that your software can deal with the world as ambiguous and fuzzy as it is. A developer that ignores the fuzziness of the world in order to write clean code, is naïve and ineffective in my opinion.
Much like advertising is 90% ineffective, but no one can predict which 90%, it seems very hard to predict which code will live on forever. Deep enterprise back end stuff gets cancelled in 6 months due to reorg / whatever, some crazy CGI written as a shell script lives for decades.
I was lucky enough that the first project I worked on professionally actually shipped. One guy on the team had been a professional developer for 12 years and it was the first product he ever had ship. The web changed that somewhat, I guess, but non-web stuff is probably still like that.
On the other hand, that first product I worked on is still in service, over 15 years later.
Honest question - can't one take pride in the fact that people are using his/her code and it is making their life better - saving money/ time etc, even if the code is not top class? Then the question is - which is more important? Make something good enough (and quickly enough) that people can start using, or keep working on something until it is "perfect"?
Obviously, this doesn't apply to life saving (or threatening) software like medical, defense, embedded systems etc.
No, not everything one does for a job is fulfilling or worth being proud of, just because someone asked for it. Often it is something useless, maybe not even what they really wanted, sometimes even annoying or harmful. Lots of us work on things which are basically useless that will go away soon. At the end of life, perhaps all you really accomplished was to stay alive in a certain sort of lifestyle.
Making it technically good is a way of making it interesting and something to be proud of. You could also make something that is yours. You could also make something that is really actually important. Without any of those outlets people will just hate their jobs and only live for their time off.
An mobile app can be scrapped in 2 years, but you might use it everyday for these 2 years. You'd want to be proud of something that will be integrated in the everyday life of someone for any time.
I used to get mad at other engineers for this. A lot of them didn't seem to take much pride in their work.
Then I realized that people take pride in different dimensions of their work. Perhaps for one person it's well-factored code, for another person it might be design and user experience and overall polish, for another person it might be the ultimate effect of the product being built on the customers (or on the business). And even on each of these there is infinite room to give a shit or not about different components of them.
All too often, being obsessive about code cleanliness is a type of bikeshedding among geeks who have gone so far down the rabbit hole that they can't engage meaningfully with the world through anything but code. Or have been so disempowered through years of cruddy jobs and sitting at the kids' table that they haven't reason to try.
It's a hard balance to strike, because there certainly have been projects where people couldn't move forward or feel pride in anything because the code was so messy. But in these situations I've found it's best to try to see the big picture and pick my battles. Code quality is only important in service to other goals.
> All too often, being obsessive about code cleanliness is a type of bikeshedding
"All too often"? Is it? I hear this all the time and very very rarely actually see it. It definitely exists, but our community seems to treat this unicorn as if it's the major issue affecting productivity.
Way way more often I see the opposite. "Just ship it! Lean startup!" a month ago leads to the inability to ship now because every part of the code you touch to add a new feature results in everything breaking. And of course there's no unit tests or any kind of documentation or even agreement among those working on it regarding what responsibilities each part of your system has. It inevitably results in the dreaded "big rewrite", if you haven't fallen behind your competitors enough at this point and are still in business.
Like you say, it's a balance and a hard one but I'm getting more and more convinced that this false consensus results in bad advice, especially when non-technical people start throwing around "just ship" and "move fast and break things" without even knowing there is a balance.
There is also absolutely no context to this lean advice that this balance is completely different for different types of programming. You will never get a good search engine written by "moving fast and breaking things", you're going to have to do some architecture/design work before you start writing code. But if you are setting up a wordpress blog to do affiliate marketing then by all means just fucking ship it.
Maybe I'm living in a bubble that's very different from everywhere else? Where people went too far with good advice? If that's the case then I want out! I will hire some obsessive bike shedders and teach them to consider time as an important factor. Way easier than trying to retrain people who think that loose coupling or not putting every method you can think of into one monster class is "obsessive perfectionism".
> It's a hard balance to strike, because there certainly have been projects where people couldn't move forward or feel pride in anything because the code was so messy. But in these situations I've found it's best to try to see the big picture and pick my battles.
This.
Sometimes it's really hard to tell when you're shaving a yak instead of fixing broken windows. What are some ways to tell you're doing the wrong one?
Yak-shaving isn't necessarily a waste of time. Sometimes you have to spend time on something locally suboptimal to get something closer to globally optimal.
With the "weekend project" idea it seems that we easily forget how real jobs often require time and struggle, even for smart people.
Put another way. . it's hard sometimes to recognize - and accept - the influence of all the other stakeholders in the project, around and above you. And sometimes it's hard to deal with the 80/20 rule and stop polishing the apple. . .the apple might not be shiny enough for you, but other people don't even the apple that you are continually shining.
I never put what you just described into words. I follow the same thought and mode processes. As of late, I feel the company is making (indirectly due to their priority of constraints) to work in Mode 2 for (VeryImportantAppForCustomer) and it's a painful internal conflict. How do you cope or handle such situations?
(This is not a snarky answer, but the truth, for me and many of my contemporaries. The internal conflicts caused by the irrationality of others can eat you alive, but only if you let them. OTOH, whenever I get paid, I realize how much harder my father and grandfathers worked for so much less and thank my lucky stars. I'm not saying that this is ideal, but it works. Another great strategy is to go home and build something for myself in Mode 1.)
I'm still working on this problem myself, but we can get some answers from the assumptions in the question:
1. Don't link perfection and pride so strongly. Find ways to be proud of other things about your work besides "perfection." Many of us are perfectionists or recovering perfectionists, and we aren't sure what's ok to be proud of besides an A+ or brushing against some platonic ideal. Pride is individual and has to do with our identity, so find what resonates with you. Try being proud of: just doing the work -- productivity, reliability, consistency, quantity; particular skills or expertise; specific aspects of quality that you personally value; the end product and the good it will do or who it will please. I draw inspiration from creative professionals (writers, artists, performers) who have strong process and show up each day to face the blank page. I like to create delightful and visually beautiful things. If you are too egoistic about your work or your job just isn't a good fit for the kind of work you are proud to do, you may need to find another job, but usually you can go far by getting in touch with what things that make you feel good about the work you do and desensitizing yourself to "flaws" by putting them in perspective. "I make perfect things" is a lame identity; dig out a better sentence for yourself.
2. "Just get it done" and then do look at it ever again! Be comfortable writing first drafts. Start early and revise. Or, save some improvements for the next release. Be aware of acceptable flaws in your software without having to compulsively fix them.
If you are working on a team, try to align your goals with theirs and accept the constraints that come from working with other people. It's also ok to have your own goals that no one else shares or supports. Expect resistance, but if you believe in it and can muster the confidence and courage, do it anyway, and people will respect you later.
Currently, I believe that the primary cause of this mode1/mode2 divide is perfectionism fueled by fear and internal resistance. As perfectionists, often the level or type of "quality" we insist on, which may be contrary to the expectations of all around us, just isn't reasonable, or isn't compatible with shipping on time or achieving our greater personal or professional goals. Or, it may be an achievable level of quality for us, but we just aren't good at sitting down and achieving it. We put off the tough design questions or stifle the very creativity we need to meet our own standard.
Another random tip: Find small ways to be creative in your work even if they don't matter to anyone else.
When all else fails, invoke the "it's just a job" frame as necessary, have a beer and don't worry about it. :)
I completely agree with you and OP's post is true for me as well. However, I wouldn't describe the reason for cutting corners as laziness, but as a need for efficiency and cost control.
Earlier, before I've had the experience I have now, I would have called this notion misguided; today, I'm not so sure. Don't get me wrong I hate cutting corners just as much as the next guy, but if you have a budget to work with, and a deadline, you simply can't write perfect code. It just has to "work" because that's what the client cares about... obviously. And unfortunately.
"It's too easy to write something crap, be forced to write several layers of crap on top of that, shout "LEAN STARTUP" at anyone who questions you and make a shamble for the exit."
This. I hear "Lean Startup" way too often as an excuse to do something shit. I'm so over it.
Doing something shit is easy.
Every situation is different but i'm generally of the opinion that you should do the absolute minimum required to achieve your objective but just do it well. If your trying to get to market asap so you don't die a horrible death i'll give you a temporary pass on the quality... unless quality is one of your core value propositions.
I would have agreed with this up until about a year ago. But I've recently discovered a new way of thinking about the development process that IMO is far superior, and more importantly, far healthier in the long run.
The way I used to think about development was that there were separate phases: building, debugging, then launching, then you stop working on it because it's "done." Then, I suppose, you go on vacation and sip Mai Tai's on the beach.
The thing is, once you get rid of the "done" phase, your whole perspective changes. The other three phases (building, debugging, launching) get mixed together in a blender. Suddenly, any time you hack something, it's okay because you're going to fix/change/refactor it later. It's all part of one big growing, changing, process -- a process that actually fits with the literal meaning of the term "development."
So it's not about pride anymore for me, it's about humility. These days, when I build something, I start off hacking something together in the quickest way possible, no matter how ugly. Then I just keep iterating, refactoring, fixing, cleaning: improving, improving, improving. So there is never a moment when you proudly show off a gleaming, fancy product and say "look, I'm done!" There's always something that works, something that doesn't -- something that needs to be completely rewritten, something that looks good and you haven't touched in months (or years).
The great thing about doing this is that it's a good way to keep yourself from being an "architecture astronaut." If you start with a hack and build refactoring into your process from the very beginning, you'll never build out more architecture than you need, because every time you use a design pattern it will be a direct response to a real need, not an imagined future need.
To conclude, I'll leave you with this quote from Walt Whitman, talking about the "deathbed edition" of "Leaves of Grass" -- a book he revised nine times during his life, which grew from 12 poems to 400 during his lifetime.
"L. of G. at last complete—after 33 y'rs of hackling at it, all times & moods of my life, fair weather & foul, all parts of the land, and peace & war, young & old"
Not sure what "hackling" means, but it sure sounds a lot like hacking!
All engineering involves trade-offs. Ideally, we'd prefer to have maintainable code that ships on time, but this usually isn't possible.
So you have to look at how much payoff you're getting from maintainable code versus shipping late. I would say that how to manage this tradeoff depends on the type of software being developed - If you're creating throwaway apps for the app stores then shipping fast is probably a more important consideration than having a maintainable codebase. If you're writing banking software for the enterprise the balance probably tips in favor of maintainable code.
You also have to take into account the constantly shifting goalposts in software development. That class you spent all day refactoring gets thrown out tomorrow.
This seems like distorted thinking. Surely there is a balance to be struck between hyper-rigor and abandoned rigor. This guy seems to have an awareness of various best practices, but no sense of perspective about their relative importance.
I'm not a programmer (at least, I'm a very beginning one), so maybe someone can clue me in: Are all best practices equally destructive if you don't follow them? Or are there best practices which can be neglected?
I'd expect that the best practices being neglected would be differently relevant to different projects, types of application, customers, etc. Would it be productive to modify the discussions of "best practices" by talking about under which context those practices are necessary or unnecessary?
Your intuition is correct, not all best practices are equally important. e.g.
1. Business data should be stored in a proper relational database such as Postgres, with a well-normalized schema. This is critical; if you don't do it before the first day in production, inconsistent data will accrue and then it's too late to solve your problems just by fixing your code.
2. Your code should be well formatted, properly indented, with variable names that are informative but not too long. This will end up being important, but if you neglect it initially, you can fix it up later, so it doesn't have to be right upfront.
3. Your code should be commented where appropriate. This is good to have, but if you neglect it initially, you can add comments later, and even if you never get around to that, you can probably work well enough without them, so if you find you don't have time to write comments, don't sweat it.
For any practice whatsoever, you can find people who will insist it's do-or-die critical (I've seen people insist uncommented code needs to die in a fire along with its authors),so you have to use your judgment to distinguish between things where you have to make a stand and things you can let slip.
This is a personality preference thing. Some people feel empowered by the open possibilities of an empty text editor, and their spirits crushed by the boring grind of polishing existing features to a fine glow.
On the other hand, there are plenty of people out there who are somewhat paralyzed by the completely open and undefined possibilities of a project not yet started, whose spirits soar at the opportunity to take something mediocre and really make it shine.
The trick is to pair with someone of the opposite type, and work together to make truly awesome stuff, and keep each other honest and not lazy. I've done this many times over my career.
Very apt given I was just moaning (zombie?) to my colleague about this. The problem is how you get your pride back though - especially when management continually gets in the way.
agreed - management is a key problem here. That extra 20 minutes to make your class readable, multiplied by 20 for all of your classes, is going to be very difficult to explain when your boss walks over to talk about why your project is overdue. There's an argument in there for time estimates to include refactoring, but that's a whole 'nother problem.
Management is a lame excuse, and you've just defined why: it's "going to be very difficult to explain".
Grow up, deal with it. Delivering bad news is part of many jobs, and programmers shouldn't expect to be exempt.
It's your choice whether or not you compromise your code. Sometimes you'll agree that it's worth it (shipping means $$$ the company desperately needs), sometimes saying no (because you know the consequences won't be worth it) will initially make people unhappy/disappointed/angry.
You can't please everyone all the time, and if you make pleasing your boss your highest priority, well, that's the price you pay.
That's a very naive viewpoint - if you present your boss with the reality of the situation, that you put off completing the project to rewrite code you've already written because you weren't happy with the results and have some vague idea that some future programmer might struggle to read it, s/he's going to look for someone who can deliver.
While you and I know that refactoring is the right thing to do, the customer/manager isn't going to say "by all means, delay completion of the project in pursuit of improvements to parts of the system that only you have to deal with". They don't see/understand the code so naturally they don't care about its state.
[note]
Obviously this is a blanket statement but it's been applicable to me and I'm sure others have experienced similar.
After a few years, you realize that if nobody wants your right thing, it isn't the right thing for business, and you have to decide if you want to resign and pursue your art with intellectual integrity, or keep working in the sausage factory that generates revenue.
If the guy who made my lunch sandwich put as much pride and care into his product as we all want to, which lasts about as long as the average modern software application, it would cost $50 and I wouldn't want to buy it.
> it would cost $50 and I wouldn't want to buy it.
I think that's a false dichotomy. There's the $6 Subway option and the hypothetical $50 perfectionist option, but you can also get a really amazing sandwich near here for $9. They make something they're proud of, and it costs more than Subway, but it's worth it.
Delivering bad news is part of many jobs, and programmers shouldn't expect to be exempt.
I agree that the typical Make-The-Boss-Go-Away Development Methodology is suboptimal. The only reason software engineers even come up with those silly estimates (which are pure bullshit, and lead to dashed expectations) is to make bosses go away so they can get back to work.
That pattern of behavior isn't what's best for companies.
On the other hand, this guy is a hired company cop that can turn off your income and fuck up your resume. You have no moral responsibility for anything but what works for you. If you have the rare good boss and a positive relationship, then deliver bad news early and be honest. If you have the typical extortionist thug ("serve my career goals or get out") then Make-The-Boss-Go-Away Development may not be the best strategy, but it's certainly morally acceptable.
I understand the premise of the article, and I think that one should take pride in creating great work. However, this kind of absolutism makes people difficult to work with. I've worked with absolutist engineers and things rarely ship and the team hates themselves by the end. Lighten up, make things work when the chips are down and move on with life. You have to take pride in the imperfect because all software is flawed, some of the flaws just haven't been discovered yet.
I think the real problem is when people have an inappropriate model of what 'quality' is. Quality criteria, when used properly, act as surrogates for the realisation of the benefits that motivated the project in the first place, or for the management of risks or costs.
What constitutes quality is context dependent - a quality criteria that is meaningful on a large project that will be used for a long time (for example, one that improves maintainability) is not necessarily meaningful on a throw away script that will not conceivably be reused.
Too many people are influenced by fashion when it comes to evaluating quality. Some things called 'best practices' will provide no organisational benefit, and might increase the cost without any corresponding gain.
Slogans like 'take pride or fuck it' probably do more harm than good - what you should do is think rationally about what the appropriate quality criteria are for a given project, keeping focused on the continuing 'business' justification for the project and all the criteria, and aim to produce something that lives up to those quality criteria. By focusing on what is optimal for your goals, you avoid premature quality optimisation / over-engineering.
One thing the author doesn't really take into account is the team dynamic...and once you're no longer the sole guy in charge of that feature/product whatever...it get's vastly more complicated (and tainted) once five or ten others have gotten their paws on the code.
The funny thing is that memory is a tricky bastard, and you're likely to remember yourself with no pride on something you did that went wrong, when at the time you were actually doing it you were very much committed and with a lot of pride.
The opposite is also true: if your endeavor did succeed, you'll probably remember the journey with the sense of "of course deep inside I always knew this was going to be great" even if in fact you didn't believe in what you were doing.
In my case, sometimes, another team fucks up, they cannot ship the product on time and I have to join to help them.
As I have to deal with bad codes, bad practices, short deadlines and a product that I don't have any interest in, I often become a zombie and get it done as fast as possible and hope I would never have anything to do with it again.
Very well put and it hits home. I always find that once I cut the first corner, I care less and less about each future shortcut or badly coded feature I implement.
However, if I truly care about the project or have a project that has been very well designed so far, I always find myself going out of my way to ensure I will be proud of it when looking back.
side project. side language... I think mine might be ocaml--can't stop looking at it, though I've tried I know there's no application other than a side project. Something has to have a bit of soul...
look at softpanorama regarding lots of years, it just gets frustrating.
I have the opposite problem. For personal projects I have to get over my fear of imperfection or I'll produce nothing at all. For work projects or anything with a deadline the pressure to make it work means I'll at least have something to refactor.
peer code reviews. I don't they are done often enough. But, as a developer, if I'm sitting writing a line of code, and I know my peers are soon going to review it, I'd be less likely to cut corners and make myself look unprofessional.
In my experience, even reviews suffer when you're working against a deadline to ship. Reviewers add comments, but major refactoring is usually marked with a "can do this post launch" (which, of course, never gets done) or people just ignore them and check-in any way (unless they comments are related to actual functionality).
In my experience, peer reviews backfire when they veer into style territory: they generate hours of non-productive work, paid by the reviewed, to generate output that has no value to the customer or management.
I used to take style comments from reviewers seriously, until I saw the code they had submitted that got them promoted.
Ok, to be serious... I perceive a dissonance here.
On one hand, we're essentially a degraded tribe. Most software engineers work for managers. We're not a profession, we don't pick our tools, and most of us work on uninspiring bullshit and are subjected to Brownian Management that has one team digging holes and another filling them in.
Management has its place, but in most companies it's a class of intermediate extortionist thugs who keep talent down: you support my career goals, or you're gone yesterday. Only the most progressive companies (Valve, Github) trust engineers to work directly for the company. No wonder our industry is so fucked.
On the other hand, the fact that Yahoo bought a small team of high-schoolers for $30 million and canned the product means that there is a lot of value in what we do. As engineers, we have a lot of muscle. We're good at something for which the world has almost infinite demand (not "programming" only, but the more abstract talent of solving problems and improving shit.) We're just terrible, as a class, at negotiation. We need to get better. We also have a tendency to want to put our heads down and ignore "the boring business stuff", then we get pissed when non-technical executives drink our autonomy milkshake. We need to stop that, too.
So here's a question: what's stopping engineers from behaving more like a profession? Is there something inherent about engineer owned consultancies that makes them unstable? If you look at accounting, consulting, law, or finance, even the biggest organizations are structured internally like small partnerships. There is of course a certain set of crazy internal politics that goes with that, but one dynamic that is pervasive in engineering that doesn't really exist in those organization is: "my boss just doesn't get what I'm doing." If you're a young, talented banker at Morgan Stanley, not only is your boss just as talented, technically, as you, but he's got a 8-10 year head start on you in the experience department.
It's not really clear to me what market forces push engineering companies to be a somewhat odd amalgam of "idea people" and "execution people." If I've got an interesting idea, why do I need to hire a bunch of engineers? Why can't I just hire a firm of highly experienced engineers who can execute my product. On the idea side that would free idea people from the burden of HR, and on the execution side that would allow highly skilled engineering teams to build up valuable institutional knowledge that could be passed down to new recruits in a structured way, instead of all that collective experience scattering to the winds every time some startup fails and the engineers head to other projects.
Secrecy is keeping it this way. Every startup wants to believe that their thing, or their idea, is the most amazing thing on planet earth, and they hide it away and don't let others touch it.
Unfortunately, in most of the environments you describe,the engineers are viewed as interchangeable cogs, quite adept at catching the shit rolling down the hill towards them. Sometimes it seems that the best you can do is not look up, with your mouth open, when you know it's about to happen.
You're still allowing the other party to frame the transaction.
Sell a vision of a positive outcome: by retaining you they'll work with someone cool and they'll get lots of money and respect out of the association. Don't sell a close match on resume filters.
It's possible that you won't be able to make the case, and that's okay. They can keep looking for someone willing to take their opening offer.
This presents an interesting challenge. I'm currently engaged in negotiating a job offer, but the last time I did this was nearly 16 years ago, the rest of my sales experience is from craigslist...
There is also a difference, in a commerce transaction the best outcome is when both parties think that they got a good deal, how the parties feel about each other only matters in as much as it will impact future potential transactions (i.e. if the buyer thinks that the seller is a sucker and charged too little then as long as the seller is happy with the price the only consequence is likely in the future if the buyer tries to take advantage of the seller)
In a transaction that aims to start a long term relationship (i.e. employment!) ideally neither side should carry negative sentiment from the negotiation. Likely you are negotiating with an HR dept or recruiter who won't take it personally, that makes it easier for the applicant to be a little "harder", the reverse doesn't apply, if the company plays hard-ball it can leave a lingering sense of resentment in a new employee (who should otherwise be entering a honeymoon period)
The last time I changed companies I took a small pay cut (bottom line, headline pay was slightly more, but benefits were noticeably worse) - it grated for a long time, even though the eventual outcome was good (acquihire)
This is a very hard problem. For me it boiled down to this: I really wanted to work at a particular company. Even though what they offered was (slightly) below my expectations, I accepted it. I didn't want to haggle because I knew this was one of the few places I would be happy working and was afraid of losing that opportunity.
This is the tough one that we all face, will asking them to move "slightly" cause you to lose the opportunity.
Having been on the other side of the hiring process, I doubt it. Finding good candidates is hard, by the time that you are making an offer you are already much more invested in the candidate as a potential employee than you are in other candidates to whom you have not yet made an offer.
But, (there's always a but!) if you are happy working there, and that's the result you wanted and needed this this was a good outcome for you. Congratulations!
That's absolutely true. Speaking from experience, I think the best way to get better at selling yourself when you're negotiating a job offer is to participate on the hiring side.
Agreed - I made the transition away from explicitly coding just over a year ago, and dealing with people, especially recruiting, was definitely harder than anything I'd done before.
One year later, it's only about as hard as programming, but I'm now on to a new thing that's harder than anything I've done before: managing.
I agree with this. We are hired to be technical experts. Though management doesn't want to hear our suggestions if it doesn't line up with their business model, or what customers are yelling about. They hear the people who pay them money over the people they pay money to all day.
It's a difficult situation to try and stand up to an employer who is telling you to do one thing when you know it's the worst possible decision they can make. It's a great idea to think we should stand up for our knowledge better, but chances are the arrogance and determination of the employer is going to stomp you right back into place, or even worse, out of a job.
If you're in a position to comfortably take a stand in this fashion, congratulations, you must be very well off. I consider myself lucky to have a boss that listens and understands when we have a concern. That doesn't mean the rest of the company does, but to have one layer between me and the real decision makers that will listen to what I have to say and protect my job in the process is a blessing.
That said, until developers are the ones with all the cash and say-so, it's going to be difficult to take this stand.
It's a difficult situation to try and stand up to an employer who is telling you to do one thing when you know it's the worst possible decision they can make.
The thing I've realized as I've gotten older and more experienced is this: The worst technical decision is not always the worst business decision. Let's over-simplify a bit and go with the notion that "the point of a business is to make money, and a highly optimized business is one that generates the maximum return on invested capital". Given that, the optimization that leads to the best ROIC might not be the most elegant technical solution or the cleanest, most maintainable, well-engineered bit of code.
Of course there is some correlation, and I'd definitely argue that many companies do make short-sighted technical decisions that are also bad business decisions. But we have to understand that the business does not (usually) exist for the primary purpose of creating beautiful, elegant, marvellous technical artifacts that will be revered for centuries.
They hear the people who pay them money over the people they pay money to all day.
Well, yeah... if the customers aren't paying them money, there won't be any money to pay us.
It's a great idea to think we should stand up for our knowledge better, but chances are the arrogance and determination of the employer is going to stomp you right back into place, or even worse, out of a job.
My experience has been that leaders at most organizations are quite willing to listen to your concerns, and aren't going to "stomp you out of a job" for stating a concern and giving your opinion. But when we (techies) start our "holier than thou, we are the techno wizards and you are all brainless sheep" routine, then yeah, what do you expect?
This "respect" thing has to be a two way street. And we (techies) as long as we desire to have paying jobs with for-profit companies as our outlet for our desire to build technology, must, must start doing a better job of understanding business, and the concerns of the "business side of the house". Of course a manager is going to get frustrated when one of us comes to him carrying on about the need to switch to functional programming in Erlang, but without any ability to articulate what the business case is.
That doesn't mean the rest of the company does, but to have one layer between me and the real decision makers that will listen to what I have to say and protect my job in the process is a blessing.
Here's a thought: learn to speak the language of the "real decision makers" and learn more about their problems, concerns, issues, etc. to the point that you can talk with them directly and have meaningful, productive conversations that span the lines between "the business" and "the technology". Ideally they would meet you halfway, but if they don't... well, what can ya do?
Your negative stereotypes about developers ('revered for centuries', 'holier than thou', 'two way street', 'functional programming in Erlang,' etc.) are making it hard for you to address parent's core points. In short, you seem to be all about developers being wrong and managers being right here and it comes across as condescending.
If you hire a pollution expert, that person's job is to provide knowledge about pollution. It is counterproductive to completely silence and fire that expert for doing their job.
If it happens that you take money from people who like pollution, that doesn't mean those people become authorities on pollution.
Unfortunately this stuff DOES happen, and there IS an asymmetry of respect - whether you recognize it or not - and you don't propose any real solution. You just throw it all back on the developer. It's all the fault of stupid, bad developers who do not respect business enough. No, sorry, that is simply not true.
The pollution expert's job isn't to pretend to be a business analyst, or flatter you. If you propose to do something which will hurt the workers or cost more in cleanup than production, it isn't the pollution specialist's job to shut up when it might make money. It is definitely their job to tell you when pollution is likely to affect the real outcomes of your enterprises. And it's definitely your job to listen when it matters. Ignore the experts at the peril of yourself and your clients.
If they are sounding off about things with no relevance like whether we are using Erlang just for the sake of it, they are not functioning as experts. But that isn't an excuse for silencing experts or characterizing people who complain about expert-silencing as holier-than-thou techno wizards who think everyone else is brainless sheep.
There is a division of labor. Maybe you are a brainless sheep about pollution. Maybe not. But the point of informing you is not to hurt your ego and it is not justified to suppress and fire experts in order to protect your ego or advance your personal career.
If you hire a pollution expert, they do their job, and you suppress their opinion - you are doing it wrong.
Your negative stereotypes about developers ('revered for centuries', 'holier than thou', 'two way street', 'functional programming in Erlang,' etc.) are making it hard for you to address parent's core points.
The point is that there are plenty of developers who are SO concerned with technical matters to the exclusion of all else that they make it difficult for business leaders to interact with them, especially when they are the ones perpetuating negative stereotypes about business leaders. Now obviously I'm not referring to all developers, but if you can't acknowledge the existence, even prevalence, of the mindset I am referring to, I would argue that you are very naive or have led a very sheltered life.
Unfortunately this stuff DOES happen, and there IS an asymmetry of respect - whether you recognize it or not - and you don't propose any real solution. You just throw it all back on the developer. It's all the fault of stupid, bad developers who do not respect business enough. No, sorry, that is simply not true.
Your hypothetical "pollution expert" is more likely to be a consultant hired to solve a short-term problem, from what I've seen, so that's not exactly an apples to apples comparison. Nonetheless, the lack of willingness of (some) developers to be proactive and make an effort to understand more about the businesses they work in, and their lack of desire to learn to communicate with the business leaders in their language, IS damaging. And I'm not saying anything like "It's all the fault of stupid, bad developers..." That's either hyperbole on your part, of you totally misunderstood what I said. FFS, I am a developer, and I hate that so many business people are as clueless as they are about technology. Nonetheless, I stand by what I said before:
If WE want business to be out outlet for creative expression (as opposed to working as pure artisans funded by patrons or some other alternative) then there are compromises we have to be willing to make.
But that isn't an excuse for silencing experts or characterizing people who complain about expert-silencing as holier-than-thou techno wizards who think everyone else is brainless sheep.
I'm not sure where you got the idea that I'm in favor of silencing experts, but that's totally wrong. I would never advocate that. But, again, the very best decision from one specific point of view might not be the best possible decision from the point of view of the businesses as a whole.
'two way street'
How is insisting that communications and respect requires a "two way street" anything negative??
In short, you seem to be all about developers being wrong and managers being right here and it comes across as condescending.
I never said that managers are always right, or that developers are always wrong. And if I am being condescending, it's towards one certain class of developers (of which I used to be one) - the ones who are "holier than thou" and who don't understand that the technical artifacts they are building are not an end unto themselves and who walk around insulting the executives for being "brainless suits" and who don't want to hear anything about how a business actually works. To those people, I offer no apology whatsoever, and would add "grow the fuck up".
And when speaking to the decision-makers, discuss the trade-offs and/or offer options. "If we try to deliver pkg DEF on the date you promised, we will have the quality problems that we had with ABC. . .and here the reasons why. . .and the customer will be just as pissed. But we can deliver the most critical, highly-valued 30% of DEF on the date that you promised. . .and the rest 6 weeks later. From a business perspective, the customer only needs that 30% at first, and this phased approach guarantees that both deliverables will be of high quality."
And when speaking to the decision-makers, discuss the trade-offs and/or offer options.
Yes, exactly. I should have said something about that in my little mini-rant above, but I ran out of time or lost my train of thought. That's it in a nutshell though... be able to talk about the relative advantages and disadvantages of various options, and - more specifically - do so in the context of what serves the long-term interests of the business.
I don't think thats something that happens at the pick a profession level
no matter which profession you pick there will be administrators, managers, or partners who will be looking to exploit workers willing to take the shit rolling downhill
and in any profession there will be workers who are adept at standing up for themselves and not taking the shit rolling down hill
at somepoint you have to stop viewing your self as a replaceable cog, and stop letting others view you as a replaceable cog, and realize that if the people you work for a view you as such, you're better off working somewhere else anyway
It's how I make my living. I'm very good at being a replaceable cog. I'm very quick when becoming a replaceable cog, and I get paid precisely because I can slot in, get things done and then leave again. This is also how I like to work - I'm constantly immersed in new systems, learning how they work and hopefully helping to improve the underlying stuff as well as churn out functionality.
This doesn't mean I take 'shit rolling downhill' from management, but it does mean that I am there to facilitate them, their ideas and their projects rather than make good stuff on their own. I play my part as best I can, advising them what to do better but ultimately deferring to them even when I know what they're doing is wrong, because they are the customer.
Hopefully (as mentioned upthread) I'll someday be able to cobble together all the wrong into a coherent set of thoughts and either become the best dev manager ever or start selling consultancy services.
Management has its place, but the power relationship is all fucked up. It should be more of a symbiotic guidance/mentoring relationship than a "serve my career goals or I fire you" extortion that generates buttloads of Fourth Quadrant Work ( http://michaelochurch.wordpress.com/2013/01/01/fourth-quadra... ).
Great article. One nit though. When making a 2d Cartesian graph with the two axis there are accepted quadrant labeling practices [1]. Quadrant I is positive on both axis, Quadrants II and IV positive on just one axis, and Quadrant III is negative on both. What you described as Quadrant IV should really have been Quadrant III. You can flip axis any which way, but the opposite quadrants will always have 1 step in between them. No big deal, but will make little sense if somebody actually tries to visualize your model.
Thanks. On the numbering of quadrants, I'm aware of that. The numbering is an order based on the value to the business.
First Quadrant (interesting/essential) is never an issue to allocate. In the ideal world, all work would be 1st quadrant. It's important and good for morale.
Second Quadrant (undesirable/essential) is what companies have to do. It's a morale liability, but too important not to get it done.
Third Quadrant (interesting/discretionary) is what one hopes will be achieved with slack in the schedule. Ideally, it'll pay off in the long term. It's good for morale, but not relevant to the immediate path-of-execution.
Fourth Quadrant (undesirable/discretionary) is the junk that should never exist.
Originally I used "category" rather than "quadrant", but quadrant implies a certain visualization, even if the numbering is different.
You've answered the question "What do you think management's role should be?" instead of the question he asked.
And how can you have a symbiotic guidance/mentoring relationship when most devs consider management to be just about the worst scum on the planet? Relationships are a two-way street.
The problem with the guidance/mentoring model of management is that it depends on your managers being consistently better than the people who report to them on the tech side and be competent at the art of management itself.
This is only workable if you're a startup that happens to have one of these rare people as founders and isn't planning on growing too much, or your company is among the most desirable place in the world to work.
The way it usually winds up working in practice is that you either promote your top tech people to their level of incompetence where they unhappily fail on the management side, or you hire competent managers who have to enforce a rather low tech competence ceiling in order to fit their command and control style.
Most developers aren't arrogant prima donnas, they want to learn from people who know more than them, but expecting someone to be able to mentor a projects' worth of people while also handling the regular management duties (hiring, delegation, oversight, resource allocation, communication with the execs, endless HR paperwork...) is setting someone up to fail.
This. I had a bad experience with a startup once in which I was the newest developer at a company and was working on a project that used a technology I was more experienced with than anyone else at the company. The whole situation did not do great things for my motivation.
The power imbalance is what causes the relationship dysfunction. Michael favors an "everyone works directly for the company on goals of their choosing" model over hierarchical managed labor.
Managers are an internal police force hired to protect the interests of owners against theft (or adverse negotiation, overcompensation, etc.) by employees. The difference is that we need police in society. Companies don't need a separate police force; ideally, they're self-policing.
I wrote about these incentive and principal-agent problems in detail: http://michaelochurch.wordpress.com/2013/03/26/gervais-macle... . Essentially, there need be no conflict of interest between employees and investors/owners. In fact, employees are investors-- of time.
Like police, most managers (by numbers) are good people but the dirty ones are really awful-- and usually get rich. In the corporate context, this is because they get so good at taking credit (the actual A players fear them) that they look like high-performers and rise quickly.
What happens in the worst companies is that owners are protected against low-level workers but robbed by the managers. They fall down hard on the "who will police the police?" question.
A small group of people, if there's full transparency about what's going on and how proceeds are divided, can be self-policing. Rick Grimes is no longer the sheriff of his group of ~10 people. They all take on the "police work"; even children. Yet cities of 4 million and nations of 100+ million need a specific police force. They can't do without them. At that scale, it's a necessary job.
By the time your company needs a police force-- it's spending a substantial fraction of its budget protecting against theft (mainly, "time theft" by an employee who favors personal interests)-- it should be scaled back and hiring made more selective, with transparency improved to make sure incentives are aligned and behavior is above-board and ethical. Cities and nations need cops because they don't fully control who gets in (or is born there); small companies aren't the same way and can be self-policing.
And how can you have a symbiotic guidance/mentoring relationship when most devs consider management to be just about the worst scum on the planet? Relationships are a two-way street.
Well, management is a class of work, not necessarily an entitled set of elevated people. The way you do it is to have a Valve or Github structure (self-executive culture) where everyone is responsible for keeping focus on business goals and the administrative work of the company. So now, management is everyone's job. Don't like how the company's being run? Go fucking do something about it. You're part of the management. Now act like it.
I don't have much love for the idea of a professional executive, though. When you have people whose job it is to Make Decisions and nothing else, then you end up with a small group of people who feel entitled to make their ideas unassailable. That's horrible. The company loses the ability to shred up a bad idea without attacking the person. No idea should be unassailable, and no one should be in the position where the job description is to Make Decisions and there's no participation in the actual work.
By the way, I don't think "managers" are "the worst scum on the planet". Many are fine human beings. Nazis and serial killers and date-raping HS/college alpha types are "the worst scum on the planet", not managers. I think management is a job that most companies structure extremely poorly.
I don't have much love for the idea of a professional executive, though. When you have people whose job it is to Make Decisions and nothing else, then you end up with a small group of people who feel entitled to make their ideas unassailable. That's horrible.
I basically agree with that, but on the flip side, I'm not convinced that management has no role. Self-organization sounds good, and it certainly works in some systems, for some value of "works". The question I have is, when the system is designed to achieve a very specific end - "maximize return on invested capital" - can total self-organization do that?
I also think it's a misnomer to suggest that executives do nothing but "make decisions". Good executives aren't just sitting ivory towers mandating things by fiat, they are conduits and coordinators. They proactively seek out information, identify problems, bottlenecks, etc. and work to coordinate efforts between all involved parties to mediate things.
I think management is a job that most companies structure extremely poorly.
Now that I agree with.
Don't get me wrong, I'm all for a very flat organizational structure, empowered employees, shared purpose and self-organization. But I think specialization of labor has a role to play as well, and I think there is some value in traditional management.
All of that said, I would love an opportunity to go visit Valve or the W.L. Gore and spend some time observing how things work there. When they day comes that we can grow Fogbeam Labs and have start having to deal with more people, I am very much intrigued by trying to keep management as minimal as possible.
"Maximize return on invested capital" is a horrible goal. It's not even the real goal of most investors. Retirees have most of their money in bonds-- stock gives better returns, and exotic vehicles do better than that (on average)-- but at that age, they don't want the risk. Investment isn't about "maximizing returns". It's about managing risk. Applying calculus and basic knowledge of derivative securities, I can come up with an investment strategy that has an EV of +50% on one year... but that has a good chance of leaving you utterly hosed. (Load up on beta using out-of-the-money call options.)
Also, the claim that CEOs are legally required to operate in short-term shareholder interest is a common misconception, but it's not true. There is no such law. CEOs aren't allowed to make decisions to the advantage of their personal financial benefit while hurting the company (that's called "stealing") and if they use dishonest means, they can go to jail. But a CEO who prioritizes a subjective health concern (sustainability, ethical business, fairness in compensation) isn't doing anything illegal. It's the CEO who gets caught embezzling funds who goes to jail, not the one who increases salaries by 10% to improve morale.
Now, there are a lot of sociopathic executives who use this "legal obligation" (to maximize short-term shareholder returns) to justify a lot of selfish and questionable things (that benefit their bosses, and thus them) but the truth about it is that it doesn't exist. It's an excuse. Classic negotiation tactic: It's Not Up To Me.
Healthier companies, I would argue, are less prone to downside-heavy but often invisible (non-financial) risks. If everyone feels micromanaged, overworked, and underpaid, then you're at risk of external "poachers" if the job market improves. This doesn't show up on a balance sheet, but it's pretty critical.
This is definitely an inherited notion, and one that's quickly (at least in the tech industry) becoming more fuzzy. I get told routinely to push back against project managers if I feel their decision making is flawed. Thankfully, it's not as common an occurrence as it could be. Our PMs are pretty good at seeing product viability and have likely considered most angles that I'll only see as I'm working on it.
But it all goes back to feeling empowered, and its up to your horizontal managers to give you that breathing room.
I wholeheartedly concur. I explained this exact phenomenon to a friend in finance, who looked at me like I was some crazy shithead. I think we need to somehow make "the boring business stuff" seem cool to engineers. It'd do wonders for our industry as a whole.
Remove the MBA crowd, sales people and lawyers from "business culture" and I suspect the technical people will embrace it whole heartedly.
No, let them stay. They have important skills (what, you want to sell rather than right code? by all means) and most of the are fine people. Just don't give them 100% of the power. They work for us, we work for them. Keep it symbiotic rather than parasitic.
On the other hand, the fact that Yahoo bought a small team of high-schoolers for $30 million and canned the product means that there is a lot of value in what we do.
Not sure that last part follows. To me, your point reads like a validation of the Fundamental Attribution Error, that there's a lot of value in being lucky.
Aaaaah, I get it! I can never tell something on HN is a Michael O'Church-ishm or something I ought to be familiar with. I am going to have to start using that one.
Brownian Motion is a fractal that is the limiting case (step size -> 0) of a Random Walk. It scales as O(x^0.5). For example, the per-day volatility of a stock might be 1%; then the per-year volatility is (in theory) 16% (assuming a 256-day year).
At work, there seems to be an accurate square-root metaphor (probably unrelated to actual Brownian motion) in the use of resources and time. You really get stuff done in 3 hours out of your 9-hour day; the other 6 are meetings and face time and bullshit. 2 days out of your work week see real, macroscopic progress; 3 are wasted. Seven of your 49 work-weeks are on projects that actually get used, and the other 42 are on manager-blessed busywork. Six years of your career end up actually mattering; the other 30 are wasted on jobs that go nowhere. So you get 3 h/d * 2 d/w * 7 w/y * 6 y = 252 hours per career that really mean something. Better make the fuckers count.
That's depressing and probably not that accurate. If you can take charge of your time and responsibility for your progress, you can do a lot better.
Brownian Management is the pointless drifting about that goes on when no one has any sense of direction. It generates the world where (as they say in many businesses) 90% of work is counteracting negative side effects of other work.
That's like 31 8-hour days. I'm trying to imagine what I could get done if I had a personal assistant to manage all the non-technical bullshit, and a month's supply of speed.
I think of the "no sense of direction" people as weather vanes. They just point wherever the wind happens to be blowing hardest. When the winds change, they do too.
>Management has its place, but in most companies it's a class of intermediate extortionist thugs who keep talent down: you support my career goals, or you're gone yesterday. Only the most progressive companies (Valve, Github) trust engineers to work directly for the company. No wonder our industry is so fucked.
Wow. In three sentences you likened management to the mafia, said they were only concerned about themselves, complained about lack of trust towards engineers, then said our industry is fucked, all without a hint of irony. It sounds like you want everyone to trust you for your genius talent but you don't feel you should have to extend any trust the other way. That's now how trust or human interaction works, and the whole statement makes you come off like an immature prima donna. You're making us look bad and I'm almost embarrassed to share the same job title as you.
I take it you've never met Michael Church. He compared Google management to terrorists that fly planes into buildings not too long ago.
All of his comments come with a deep disdain for management and a grand philosophy on programming in the abstract. At least the chip on his shoulder for Google wasn't around for this comment.
Most companies give managers the ability to be extortionists if they want to be. That doesn't mean that all managers go black hat. Many do not.
I've seen companies where 90% of the managers were decent people, and companies where zero percent were decent people. It seems to average about 70, but that bad 30 percent can do a lot of harm.
In my experience, managers are like programmers. Good managers can be really effective. Most are semi effective. Some are downright harmful. For the most part though companies seem to have limited ability to tell which is which. I went through a major re-org over year ago. Just from the management switch my stress level went down by a factor of 10.
Considering pattern recognition is one of the supremely human qualities, why would it be necessary to 'be one' to 'know one'? Why not just recognise one?
If you ask why this happens and go as deep as you can, I think you'll find that the root of the problem is not per se management, but politics/government/regulations/legislation.
This is a good sentiment, and we should have the pride to create quality at all times...
But the appeal of the quote comes from that magic word "professional," and the respect, autonomy, and pay associated with it. Promising that the Respect and Pay Fairy will anoint you a Professional once you become the very best FactoryBeanListenerObject builder in the bowels of Enterprise doesn't tell the whole story.
The word has suffered the same fate C.S. Lewis ascribed to "gentlemen" and "Christian"
"When a word ceases to be a term of description and becomes merely a term of praise, it no longer tells you facts about the object: it only tells you about the speaker’s attitude to that object. (A ‘nice’ meal only means a meal the speaker likes.) A gentleman, once it has been spiritualised and refined out of its old coarse, objective sense, means hardly more than a man whom the speaker likes. As a result, gentleman is now a useless word."
For more on this topic, I highly recommend michaelochurch's November essay on what a true profession of programming might look like.
that special Java/C# + ORM / (N)Hibernate + XML + SQL kind of development hell.
There isn't necessarily anything inherently wrong with Java, C#, ORMs, XML, or SQL. All are pretty useful ways to solve certain classes of problems, taken on their own.
That said, there are definitely "development hell" projects that feature all of those things, but I believe you can have "development hell" in any language, using any libraries, and any persistence technology.
And anyway, if you think writing C# or Java code is bad, trying writing RPG/400[1] using SEU[2] on an AS/400[3] sometime. That stuff'll leave you shuddering and sweating in your sleep, and walking around with a blank stare on your face, drooling and mumblng "Ia! Cthulhu Fthagn! Ph'nglui mglw'nfah Cthulhu R'lyeh wgah'nagl fhtagn, %!@ ^^&!@(, (#!^H NOCARRIER".
Oh, yeah, no doubt. It's fun to make fun of mainframes, and IBM, etc., but the reality is that they invented a ton of ideas that are only just now migrating into the commodity hardware/software world, and/or consumer devices.
Developers in general would probably be well served to do a better job of acknowledging our own history and maintaining more awareness/context regarding what has come before.
Interesting... then why are there entire systems of thought in management theory centered around motivating people to work?
It's a warm and fuzzy quote, but humans don't work this way. If we're not sufficiently motivated, no force on earth is going to allow us to do our "best job".
A good manager knows this situation and can help their team through it. Sadly, there really aren't many good managers out there at all.
+1 nice sentiment. I'll have to get "A professional is someone who can do his best job even when he doesn't feel like it" laser etched on the top of my screen
If you're writing some deep enterprise level back-end stuff that is going to be integrated in a large, expensive system, obviously it really is worthwhile to do it right.
If you're cranking out another piece of shit marketing website, or even better, anything app or mobile related, no matter how much planning and testing and pride you put in to it, it is almost always completely worthless in a couple years.
Everything is changing so fast right now, the platform, device, language, database, etc, may not even exist in 5 years. 5 years! That's a hell of a depreciation schedule for a $200k project.