42 ms·

Take pride or fuck it

250 points by jshakes 14y ago

cmdkeen 14y ago
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.
- alexjeffrey 14y ago
  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.
  - taude 14y ago
    If it's really only 20 extra minutes to do this, maybe less time on Hacker News :)
  - onemorepassword 14y ago
    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.
    - alexjeffrey 14y ago
      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.
      - Evbn 14y ago
        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.
        bluesnowmonkey 14y ago
        > 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.
    - michaelochurch 14y ago
      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.
cynusx 14y ago
ship it and write up a janitor card to clean it up. pick up the janitor cards when you're low energy or waiting on somebody else.
dave_sid 14y ago
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.
- Evbn 14y ago
  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.
- rohitnair 14y ago
  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).
taude 14y ago
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.
seivan 14y ago
I see this in myself. It hits right at home. Very well put! There have been occasions I fall in love with a particular solution because it was so elegant and I just have this urge to tell everyone about it. But there have also been the opposite...
TheFuture 14y ago
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.
- dave_sid 14y ago
  LOL - "If you're cranking out another piece of shit marketing website, or even better, anything app or mobile related"
- Roritharr 14y ago
  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...
  - michaelochurch 14y ago
    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.
lukethomas 14y ago
"covered my codebase in bacon" - I got hungry after reading that.
michaelochurch 14y ago
Lions get a better deal: take pride and fuck it. 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.
- jbattle 14y ago
  Which profession doesn't work under the meddling of administrators, managers, or partners?
  - taytus 14y ago
    I don't think the problem are the managers per se, but our lack of confidence on the negotiation process.
  - michaelochurch 14y ago
    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-quadrant-work/ http://michaelochurch.wordpress.com/2013/01/01/fourth-quadra... ).
gavinflud 14y ago
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.
iTrollFreely 14y ago
"untitled.txt"? what kind of p.o.s editor is he using to code
- Evbn 14y ago
  It is a program in Textile language, a modern language designed for multithreaded programming.
edw519 14y ago
Great post! I've felt this way for years but never put words to it quite like OP just did. Thank you. I also work in 2 modes: "1. Make it perfect." and "2. Just get it done and hope I never see it again." I used to do everything in Mode 1 and took great pride in my work. Now I use this logic: if (LowLevelCode) or (VeryImportantAppForCustomer) mode 1 else mode 2 Funny, the longer we build software, the more we rationalize and the smarter and lazier we get.
- jrs235 14y ago
  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?
  - edw519 14y ago
    How do you cope or handle such situations? Pay day and beer, ususally on the same day. (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.)
  - dgreensp 14y ago
    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. :)
dangrover 14y ago
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.
- RougeFemme 14y ago
  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.
- dmiladinov 14y ago
  > 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?
  - pekk 14y ago
    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.
coenhyde 14y ago
"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.
marmot1101 14y ago
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.
bartwe 14y ago
After several bouts of not programming due to perfectionism driven fear of failure, making 'crap' beats perfection.
parnas 14y ago
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.
johnw 14y ago
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.
martinced 14y ago
"As soon as I lose pride in something, I stop caring about it being good." The one quote to deal with that is simple: "A professional is someone who can do his best job even when he doesn't feel like it" That's what I keep in mind when I have to work in that special Java/C# + ORM / (N)Hibernate + XML + SQL kind of development hell. :-/
- ipetepete 14y ago
  +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
- mindcrime 14y ago
  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". [1]: http://publib.boulder.ibm.com/infocenter/iseries/v5r3/index.jsp?topic=%2Frzahg%2Frzahgrpg400.htm http://publib.boulder.ibm.com/infocenter/iseries/v5r3/index.... [2]: http://pic.dhe.ibm.com/infocenter/iseries/v7r1m0/index.jsp?topic=%2Fcl%2Fstrseu.htm http://pic.dhe.ibm.com/infocenter/iseries/v7r1m0/index.jsp?t... [3]: http://en.wikipedia.org/wiki/IBM_System_i http://en.wikipedia.org/wiki/IBM_System_i
  - pjmlp 14y ago
    Only recently I discovered that OS/400 is bytecode based for all userland software, with a JIT integrated into the kernel. Which means Android and Windows are kind of following a path similar to a mainframe OS. Interesting for language geeks. Anyway I haven't touched one since 1994.
ipetepete 14y ago
"I've unleashed the hounds of hell and covered my codebase in bacon." Best quote of the week.
linhmtran168 14y ago
Agree with the article wholeheartedly. 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.
eeeeaaii 14y ago
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!
unoti 14y ago
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.
jcmontalbano 14y ago
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?
- rwallace 14y ago
  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.
A1kmm 14y ago
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.
mmv 14y ago
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.
endgame 14y ago
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.
stevebot 14y ago
I wish I could do this, but I know I won't make the deadline if I do.

250 points by jshakes 14y ago

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.

alexjeffrey 14y ago
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.
- taude 14y ago
  If it's really only 20 extra minutes to do this, maybe less time on Hacker News :)
- onemorepassword 14y ago
  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.
  - alexjeffrey 14y ago
    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.
    - Evbn 14y ago
      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.
      - bluesnowmonkey 14y ago
        > 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.
  - michaelochurch 14y ago
    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.

cynusx 14y ago

ship it and write up a janitor card to clean it up. pick up the janitor cards when you're low energy or waiting on somebody else.

dave_sid 14y ago

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.

Evbn 14y ago
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.
rohitnair 14y ago
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).

taude 14y ago

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.

seivan 14y ago

I see this in myself. It hits right at home. Very well put! There have been occasions I fall in love with a particular solution because it was so elegant and I just have this urge to tell everyone about it. But there have also been the opposite...

TheFuture 14y ago

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.

dave_sid 14y ago
LOL - "If you're cranking out another piece of shit marketing website, or even better, anything app or mobile related"
Roritharr 14y ago
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...
- michaelochurch 14y ago
  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.

lukethomas 14y ago

"covered my codebase in bacon" - I got hungry after reading that.

michaelochurch 14y ago

Lions get a better deal: take pride and fuck it. 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.

jbattle 14y ago
Which profession doesn't work under the meddling of administrators, managers, or partners?
- taytus 14y ago
  I don't think the problem are the managers per se, but our lack of confidence on the negotiation process.
- michaelochurch 14y ago
  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-quadrant-work/ http://michaelochurch.wordpress.com/2013/01/01/fourth-quadra... ).

gavinflud 14y ago

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.

iTrollFreely 14y ago

"untitled.txt"? what kind of p.o.s editor is he using to code

Evbn 14y ago
It is a program in Textile language, a modern language designed for multithreaded programming.

edw519 14y ago

Great post! I've felt this way for years but never put words to it quite like OP just did. Thank you. I also work in 2 modes: "1. Make it perfect." and "2. Just get it done and hope I never see it again." I used to do everything in Mode 1 and took great pride in my work. Now I use this logic: if (LowLevelCode) or (VeryImportantAppForCustomer) mode 1 else mode 2 Funny, the longer we build software, the more we rationalize and the smarter and lazier we get.

jrs235 14y ago
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?
- edw519 14y ago
  How do you cope or handle such situations? Pay day and beer, ususally on the same day. (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.)
- dgreensp 14y ago
  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. :)

dangrover 14y ago

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.

RougeFemme 14y ago
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.
dmiladinov 14y ago
> 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?
- pekk 14y ago
  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.

coenhyde 14y ago

"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.

marmot1101 14y ago

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.

bartwe 14y ago

After several bouts of not programming due to perfectionism driven fear of failure, making 'crap' beats perfection.

parnas 14y ago

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.

johnw 14y ago

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.

martinced 14y ago

"As soon as I lose pride in something, I stop caring about it being good." The one quote to deal with that is simple: "A professional is someone who can do his best job even when he doesn't feel like it" That's what I keep in mind when I have to work in that special Java/C# + ORM / (N)Hibernate + XML + SQL kind of development hell. :-/

ipetepete 14y ago
+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
mindcrime 14y ago
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". [1]: http://publib.boulder.ibm.com/infocenter/iseries/v5r3/index.jsp?topic=%2Frzahg%2Frzahgrpg400.htm http://publib.boulder.ibm.com/infocenter/iseries/v5r3/index.... [2]: http://pic.dhe.ibm.com/infocenter/iseries/v7r1m0/index.jsp?topic=%2Fcl%2Fstrseu.htm http://pic.dhe.ibm.com/infocenter/iseries/v7r1m0/index.jsp?t... [3]: http://en.wikipedia.org/wiki/IBM_System_i http://en.wikipedia.org/wiki/IBM_System_i
- pjmlp 14y ago
  Only recently I discovered that OS/400 is bytecode based for all userland software, with a JIT integrated into the kernel. Which means Android and Windows are kind of following a path similar to a mainframe OS. Interesting for language geeks. Anyway I haven't touched one since 1994.

ipetepete 14y ago

"I've unleashed the hounds of hell and covered my codebase in bacon." Best quote of the week.

linhmtran168 14y ago

Agree with the article wholeheartedly. 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.

eeeeaaii 14y ago

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!

unoti 14y ago

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.

jcmontalbano 14y ago

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?

rwallace 14y ago
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.

A1kmm 14y ago

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.

mmv 14y ago

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.

endgame 14y ago

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.

stevebot 14y ago

I wish I could do this, but I know I won't make the deadline if I do.