It's very hard to justify this "laziness" to managers sometimes. But what's more shocking is that the "lazy" group had a working system and that apparently was not valued as much as the other group, continually fighting fires.
I would argue that you can be productive for more than 8 hours a day, so the programmer I want (obviously) is one that works nights and weekends but gets shit done the whole time.
Do you think that if you worked nights and weekends (say another 20 hours a week) your total productivity would be diminished vs. your normal week because those extra hours aren't productive?
Burnout and tunnel vision would certainly ensue in the medium term; or someone external would intervene and snatch the programmer from you, by proposing them a better deal. It can still serve you well, depending on the market you're in, and how steep / long is the learning curve of your codebase - but I would argue it's not the best strategy in the long run.
>Do you think that if you worked nights and weekends (say another 20 hours a week) your total productivity would be diminished vs. your normal week because those extra hours aren't productive?
Yes, but it depends on what type of work is required.
In creative work: if I don't get enough sleep, enough exercise, enough relaxation time, my personal productivity falls to at most a quarter of normal. Total productivity is surely less.
In grunt/repetitive work: my productivity is affected a little but probably not enough to decrease total productivity, and I've noticed my work is appreciated more because I appear to be more 'busy'.
Some oil & gas companies, like Chevron, believe so much that over-working your employees leads to an overall loss in absolute productivity and work quality that they give many engineers every other Friday off.
Of course, you could rightfully question whether this is actually increasing the company's productivity or whether they are just so flushed with billions of oil dollars that they can afford to pay their engineers full-time salaries for slightly less than full-time hours.
That's...not entirely true. They work what are called 9-80s, so they put in 80 hours over the course of the 9 days every two weeks that they do work. So they actually end up working more than 8 hours on the days they do work.
Source: I worked for one of the majors w/ this policy.
Well, my roommate is on this schedule and most certainly does not work more than 8 hours per full working-day on average. He might work 8 hours including the time driving to and from work. And on the Fridays he doesn't have off, he only works until noon or so.
Maybe his case is not normal?
Edit: Granted, I think another reason for this is that, based on his descriptions, there's a remarkable amount of bureaucracy involved in the oil companies. It's a very, very complex industry, and while it moves quite fast on a global scale, it moves very slowly for most individuals involved in it. His training program alone lasts a few years, so he won't really be a highly productive member of the company for quite some time.
This has been studied quite extensively, for the majority of people productivity plummets if you consistently work more than 8 hours a day. You may be able to cram it for about two weeks but that effort needs to be payed back with more rest if productivity should stay the same.
That's something I'm really interested in, basically figuring out your own productivity curve. If you work 8 hours a day productively, if you want to maximimize your weekly productive should you work both weekend days?
For something that you're "really intrusted in", you really should familiarize yourself with the studies on workday/week hours and long term productivity.
It will however put the kibosh on your plans to extract more value from your employees by working them to the bone.
You're basically treating employees like their sole purpose in life is to be productive and nothing else. I honestly don't know how much you'd have to pay me to work 80 hours a week. I think it'd have to be in the range of billions so I could do it for a few months and then retire, heh.
Those extra hours have negative productivity. They cause you to make mistakes which take more time to fix than you gain in the extra hours. (Mistakes which you also make in the rest of the week by being more tired.)
Read Peopleware if you haven't already. It covers myths like the 60 hour work week and outlines how to make software projects productive and predictable.
Can have negative productivity. I am all in favor of keeping work loads light, but in real businesses edge cases come up.
We recently just got through a couple of really harrowing sprints because of such an edge case - a lot of hours were worked. Quality remained high. I personally am satisfied with what we delivered - while it could have been done better with more time, the tradeoffs were all understood and accepted.
The flip side of that is that this kind of thing happens to a given team here maybe once or twice a year. The rest of the time is sane, normal working hours and load. If it were like this a significant portion of the time, then you'd start seeing the kind of patterns you're describing.
It happens but you need to recognise the true cost. You always pay interest on the other side at some point. At the same time you weaken boundaries and introduce instability.
Well, does not really apply to my current job, but when I'm very interested in a project, if I don't put lots of hours towards it I can't produce anything more (or have fun in any other activity).
"so the programmer I want (obviously) is one that works nights and weekends but gets shit done the whole time."
The programmer I want/to be is the one who gets shit done the whole time without working nights and weekends and actually spends time doing other things that also matter like family, friends. This way, he/she stays sane and more valuable.
Short term, you might see increased productivity. Medium term, productivity is going to go down because of exhaustion. Long term, unless programmers are just dying to work for you specifically, productivity will go way down because the best people will leave to work for someone who doesn't abuse them.
There should really be a 50% premium for the working hours, plus a unicorn premium on top of that.
People willing to work a 60+ hour week are relatively rare. If you genuinely need that over the long-term, you have to pay for this rarity: in addition to the extra hours.
> I would argue that you can be productive for more than 8 hours a day
I agree with you, but not on a single task.
If you want to hire someone who can program for a couple of hours, design your marketing material for a few more, work on your IT infrastructure for another couple of hours, and then maybe go off and do some sales work and meet with the rest of your team, you might have something that works.
Of course, if you find someone who can do all those things well, they are probably off working on their own business and couldn't care less about what you are doing.
At least, as a programmer, I know that having to switch into other modes really diminishes my ability to focus on the problem I'm solving (programming).
Your day sounds like a way to turn a 40-hour programming project into a 80+ hour project.
Maybe I cannot speak for everyone, but two or three hours is really about all I can take before I need a break of some kind (to stretch, to eat, whatever), and at that point you end up switching contexts anyway, so you may as well jump into something completely different when you return. It is no more costly to "load up" something new than to "load up" what you were working on before once the switch has happened.
Now in the real world, where people expect you to do just one thing, I often do multiple two, possibly three, hour stints, with context switches in between each. However, I feel a lot better on the days when I'm able to do different tasks on each switch rather than coming back to the same task each time. You, naturally, still have to give that task your undivided focus while you are working on it. Trying to manage everything at the exact same time will definitely lead to what you suggest.
Of course there are no hard rules. If, for example, you're having a good programming day, maybe you'll put in four straight hours before you feel the need to stop. It is not like you have to put your metaphorical pencil down as soon as the clock strikes the two hour mark.
I interpreted it as saying the only way you can expect more than 8 hours of productivity constantly from programmers is if they do multiple tasks. And not saying that it would be ideal to have programmers do everything.
Having done just that I later about for months before I started to see very noticeable effects. It took me a month to recover to a point where I wanted to look at code again. Half a year before I wanted to give it another try.
In comparison I got a lot done when I spent two months working on code 4-6 hours a day including weekends.
While you can't judge programming and knowledge work in general the way you judge physical labor, it would help a manager to know when programmers are likely wasting time and company money. This is especially important for resource constraint startups.
I guess the question should be, Are your programmers working primarily to serve your need as a business or are they devoting their effort and time on work that is more aligned with their own ideology (choice of technology and approach).
A few months back I was in Philly talking to a startup founder whose company was at death's door because he kept hiring developers who came in and replaced whatever the last person did because it wasn't what they preferred. This phenomenon is a much bigger problem than the question of whether programmers are working hard or not.
It can be really unappealing to deal with an existing codebase which contains whimsical choices, and ideally a team should have a turnover low enough to ensure continuity and consistency of coding style. And to overwork people it's hardly a good strategy to keep people sticking around. The problem you mention might be connected with the issue of overworking more than it seems, imho.
You are right, working with someone else' code can be quite a task sometimes but it comes with the territory. It almost always happens that a programmer attempts to redo work and end up creating the same problems that the original developer already solved.
I think it really comes down to perspective, once you learn to view programming as a means to an end, not an end in itself, I think you become more tolerant of what looks like shabby code.
Until the shabby code starts making even the simplest changes, take days to complete.
Keeping code in good condition, delivers a large amount of business value over the long term. Shabby code delivers business value short term, but reduce it long term.
short term benefit vs long term value is certainly something to consider...
Going back to my earlier point, the important thing is for managers to know how to recognize when a developer's effort is aligned with business interest as opposed to simply allowing developers do what serves their own ideology.
I think once you do that, it becomes easy to discuss/address things like technical debt.
This is, I think, a very relevant case for the "Non-technical co-founders need to learn to code" argument. There are always problems with judging how much work is being done in any creative project - heaven knows my best marketing work comes in spurts that tend to happen at 2 AM. But the larger issue here is that the guy issuing raises has no idea what is actually happening in the codebase.
I'm by no means an incredible engineer, but I've spent a couple hours a day over the past few months building basic Ruby/RoR apps, and it makes an enormous difference. Of course, I still have a long way to go before I'm able to really estimate anything, but if nothing else I understand why my co-founder would just sit there for hours with a whiteboard and model data. I know that "burnout" is a real thing, especially when you're not overcoming little bugs you've had for a long time. I know the value of getting a second pair of eyeballs on some code. etc.
It's just impossible to understand what you don't understand the technical aspects of what you're trying to do.
No, you don't need to be able to code to understand that the team that's working fewer hours is generating the same results. You only have to understand what the business needs are and how well they're being met per dollar that you spend. In the article's example, the manager needs to understand how well his two cable provisioning systems are meeting the needs of his customers. That has nothing to do with code.
If a manager's only metric about how well his line of business is functioning is how much overtime his employees work, then learning to code will not make him any more competent. It's more likely that if the manager learns a little bit about coding, he'll think that everything his team does is easy (since he never tried to implement anything complex). Also he'll be more likely to be an annoying micromanager, since he'll think that he actually understands the complex issues that his team is grappling with.
The issue here is that "does it work" isn't a good enough metric for code quality. If two engineers deliver code that accomplishes the same task, one might have made it readable, testable, scalable, etc. and the other just jammed it together to accomplish the desired result, the manager that can't read code won't know the difference.
Yes, in the long term, the shortcut taking programmer's shortcuts will catch up to him (code will break, you can't add more people to work on his code, etc.), but it could be too late for the manager.
Sure; but he or she might have a better idea than someone who doesn't know `=` from `==`, right? And do you really want to turn your best engineers into managers, when they'd be much happier and more productive building themselves?
EDIT: Of course, I do agree with you. It's just worth keeping in mind that perfection can be hard to reach, at least in the conventional manager-evaluates-engineer format.
Right that's true, it does come down to the manager's level of expertise. I guess my point is that you need someone with a solid understanding of code to review their output, not just a manager evaluating "does it work", whether that reviewer is another senior engineer, the CTO, the technical co-founder, etc.
You're right. I'm not saying "Hey, I spent a month and now I can tell my co-founder how it should be done" - the first couple months is just the beginning. But I feel like I can relate to/understand 10% of the process when before I could relate to 0%, and that's a big jump.
I can see how it could get out of hand if I started questioning things I don't understand, beating my chest and saying "Don't tell me that, I know how to code," but now at least I can have a discussion with him without everything going over my head. It's difficult to explain how big of a difference that makes.
We've actually had exactly this problem on a team, where our manager had a rudimentary understanding of database design and became very insistent that the team should do things his way. It eventually got to the point where the team would have to spend 2 hours explaining a design decision to the manager, instead of spending 15 minutes to implement it. It was particularly irksome, because the manager would refuse to read any best practices or take any advice, and became defensive about decisions he didn't understand instead of asking them to be explained more clearly.
That said, I think this issue was caused by 10% technical ineptitude and 90% ego.
I was in a similar situation once. A manager with zero development experience was overruling our decisions on how to architect the application and the workflow.
I was young and needed money badly at the time so I went along with it, but if I ever found myself in a similar scenario again - where some chest beating bozo is telling me how to do my job - I would explain that I'm not the best fit for their work culture and promptly give my resignation notice.
Unless you're desperate for cash or something, don't ever subject yourself to such blatant disrespect. It's a truly soul crushing experience.
Actually, it's a very relevant case to keep non-technical co-founders as far away from the code as possible.
Educate founders to entry-level coding skills (or below) and they will have entry-level abilities at estimating project technical scope and difficulty.
Funnily enough, I have two bosses – one has a PhD in computer science and one in geology. The latter one usually is much easier to deal with and understands more of what's going on.
This might in part be because the geologist (a) is in our office and doesn't just burst in every two weeks and (b) does at least a little scripting from time to time, while the other one didn't write a line of code in years.
You seem like you've learned the right lessons, but more often I've found that learning just enough to be dangerous makes managers worse at this.
Take the example in the article, where the developer who made a well factored application was "overcomplicating" the code. It's not uncommon for a beginner who understands the means of programming but hasn't been bitten by the results of bad design to make poor decisions for the sake of experience that need to be made up in extra work later.
Having a manager who actively encourages solutions like "Why not just copy the entire method and wrap it in an if statement?", or "Can't we just comment out the existing code that's incompatible with this new feature?" can be demoralizing - if they're in a position to actually make that happen, it's even worse.
Same thing with system administrators. If you're a bad sysadmin your stuff is going to break constantly and you will look like your working hard to fix it. If you're good at it, hardly anything will go wrong and to management it looks like you sit on your butt all day.
Yeah I saw a case when sysadmins left an exchange database to grow to crazy size and then it failed, cue days of trying to restore backups which also failed because disaster recovery practices had never been written or tested. After about a week I expected everyone to get sacked, instead they got a literal standing ovation for their ceaseless scrambling around.
There's a guy in my company who rose to upper-middle management faster that anyone I've ever seen. The key to his success was constantly running around, getting social exposure by talking to everybody (about inane bullshit most of the time) and trying to make himself look important.
In the meantime, we lost a really good engineer who was thought to be a slacker because he was a quiet guy and wouldn't expose himself too much.
This sociopathic and pathologic behavior is very common in companies run by "business people with ideas" instead of engineers. It's all based on chest beating, who you know and how much of a smooth talker you are. It's like being in high school all over again. Meritocracy is nowhere to be found.
I once introduced a fairly serious bug into our software. It caused, probably, a 40% drop in perceived performance. The bug was based entirely on me misunderstanding what one of the EE's told me. I fixed it in the next release and was lauded in a meeting for improving performance.
SysAdmin/DevOps here. My current environment is "Everything works, but unless you're at your desk 8-10 hours a day minimum, you're not working." Also, expected to be on call 24/7.
Not every place is like that. But I find it to be the majority.
Programmer here. I've been in two places like that. One relied on its reputation to leverage and squeeze people to the last drop; the other, more realistically maybe, just paid a lot and expected a great deal of work and a constant display of busyness. Both companies eventually had to face very serious issues caused by an unnaturally high staff turnover. Admittedly, a great company culture can be seriously financially rewarding if the management is able to create and cultivate it. Since not everyone has this ability and, let's face it, some software products are just dull to build, but still have a market, I guess that a moderate amount of squeeze works for long enough for the average so-so manager to justify their salary until they leave themselves, without giving any real benefit for the company in the long run :(
This is interesting. And definitely a "real thing". To me it raises an interesting question about effectively demonstrating value to one's higher ups.
It's a little sad that pushing for "visibility" is so important, especially in large corporations, but it helps to put yourself in the boss's shoes - how will he/she know you're doing good work unless you blow your own trumpet?
Arguments that a good boss "should just know" certainly have merit, but it's up to each of us to determine whether our own boss fits in that category and emphasize our accomplishments accordingly if we're to be "performance reviwed" with bonus etc depending on that perception.
This (as most things are) is far easier said than done. Someone who is in the business of "putting out fires" can easily cite the numerous times they tirelessly fixed a production bug or worked a 60 hour work week. Managers quickly understand those concepts as they see a direct correlation to their own job or can visualize the impact.
Explaining that you "wrote a unit test suite that has minimized the long-term impact of bugs" or that you architected an elegant solution to a design issue that will help foster extensibility and testability in the long-term will also likely be met with "this guy is blowing smoke up my rear" because there is no way for the manager to verify those claims.
Anecdotal case, I worked with an individual who was labeled as a "trouble maker" who everyone said constantly raised issues that weren't relevant and that didn't do any real work. The individual ended up quitting because they got sick of the work environment. Next release cycle, all of the projects they were a part of began falling apart. The contribution that this person had been making was identifying shortcomings of the requirements, processes, implementations, and verification steps. Nobody could see past their own bias and lack of understanding about what was happening. They just kept getting frustrated (including management) because from their perspective this individual was just "creating more work".
I agree with you, I hate that so many places are like this. It really isn't right, and rewards the wrong behaviours. From my own perspective I have been lucky for the most part in having had good managers/team leads even in organisations where this culture pervades.
It's taught me to be wary though and "manage upwards" until I feel confident my own direct manager appreciates and recognises my input.
Raising awareness with my manager's manager is harder: still working on that, I suspect and element of "HELLO HERE I AM FIXING STUFF, IT'S QUITE LATE, BEEN DOING IT FOR A WHILE NOW, OK THEN GLAD WE'VE CONFIRMED WE ALL KNOW THIS" is still needed!
> When people are doing a physical task, it’s easy to assess how hard they are working. You can see the physical movement, the sweat. You also see the result of their work: the brick wall rising, the hole in the ground getting bigger. Recognising and rewarding hard work is a pretty fundamental human instinct, it is one of the reasons we find endurance sports so fascinating.
We've all heard about the stereotypical manager-perception of "effort invested will be proportional to results delivered!", like the article laments. But this analogy breaks down really quickly.
Let's use an example that's not from software to illustrate the point -- in fact, let's use the author's own example, laying bricks. Who would you rather hire?
-- Bricklayer A: Takes 2 weeks to finish a wall, stays late every day to finish the job, finally builds a brick wall of passable quality.
-- Bricklayer B: Finishes your wall in two hours because he realizes there's a better way to lay your bricks, and builds a wall of excellent quality.
I feel like most people, even managers of non-software folks, would rather hire B. At least, I certainly would.
So I think the premise of the article is wrong. There's something deeper going on, and dismissing it with "managers want to reward hard work, and creatives don't look like they're working hard" is an explanation that is "neat, simple, and wrong" [0].
Exactly. I think the underlying issue, for both bricklayers and software developers, is that managers need to have the competence to accurately evaluate the work of their employees. If they can't do that properly, they're hurting their businesses and should be retrained or replaced. (Unfortunately, these managers' managers are also frequently incompetent at evaluating their work, so the bad managers keep on doing what they do and good employees leave.)
I've experienced management that could only evaluate your productivity based on hours in the office. Now, I generally did pretty well at that one, because I was doing a lot of hours, but if I had to come in late because my apartment flooded he was all grumpy, because the one tool in his toolbelt wasn't working.
Who said that being a good manager was easy? Managers also need to work hard to deserve their high salaries. Lazy managers who can't be bothered to do their jobs properly should be fired.
Probably by talking to him. It's not hard to tell if a manager has no clue about what you do.
If he doesn't, then he's probably using some silly and lazy metric like "hours in the office" or "lines of code written per day". If he does, he probably took the time to learn about your job and make a more accurate assesment of your work.
Really, as a programmer you are supposed to know lots of things, learn some more and work hard; but the guy above you cannot be bothered to learn some useful skills in order to asses your work? What kind of logic is that?
A good manager still knows what their employees are working on - not necessarily in detail but they should be able to describe the user side of the project comfortably and have some idea about which parts are the most challenging.
They shouldn't measure either of those things: they should find a valid proxy for those things, such as the output you produce. Frankly, if they're measuring the process instead of the output, then they're likely to just ultimately be micro-managing.
A decent manager should make themselves available to the team, but not interfere with the team unless something's going wrong, or appears to be going down the path of 'going wrong'. They should measure the team by their output, and use that to determine whether things are going wrong, or are about to go wrong.
Attempting to measure a team by their process makes the assumption that the manager is capable of understanding both the current process, and the maximally optimal process against which to compare the current process. It's far safer for both the manager and the team for the manager to avoid such endeavours, and instead measure the output itself against the optimal version of the output, because the output should meet business/product goals against which it can be assessed.
Agile PM would actually put process first and simply measure output because poor processes impact everything else and give you no chance of sustained success. You should be trying to optimise the conditions for optimal outcomes via facilitation. That's the reason you measure, to understand and improve your success as a facilitator for the whole team, not to track individual productivity. You shouldn't reward or penalise anybody on outcomes themselves but on ability and diligence (which should be blindingly obvious to a technical manager given any degree of engagement with the development process).
I think the explanation still functions if you also add the belief that work is largely incompressible. If most professional bricklayers take a year to build a passable house and someone tells you they can do it in two days but wants 10x the rate, that would smell a little fishy.
Your analogy fails: There's just not a 100:1 difference in effort to lay a brick wall. Maybe 3:1. But you still have to pick up each brick, no matter how talented you are. This is why bricklaying (and other physical processes) are bad analogies to computer programs.
I think you actually get at the crux of the issue, inapt comparison to programming though bricklaying is. If the analogy is going to carry, we should be able to describe an interview process that will distinguish the 2hr vs. 2wk bricklayer. Yet even in programming, this reverse-engineering of interview techniques doesn't exist.
That's because being convincing at interview is much easier to learn than writing good code or laying bricks fast. So for a bad coder (or bad bricklayer) it makes sense to train for interviews instead of training for the actual job.
One thing that is hard to work around is where the interviewee must demonstrate their skill first hand (e.g. implement FizzBuzz followed by strcpy and a binary search.)
Many common interview questions are too indirect (Show me a certificate; Answer this trivia question about a Java API from 1997) or misguided attempts at personality tests (How many sewing machines are there in West Virginia) all of which one can prepare for without having the actual ability to do the job.
These kinds of questions can still work, as long as they have not yet made it into "How to succeed at interviews" type books. Or when the applicants you want to filter out cannot resist outing themselves even with training (e.g. "Tell me about a time when you have been wrong / publicly changed your opinion" will probably always be a useful filter.)
Bricklaying machines where bricks go into a bucket and out the other end comes a horizontal wall. You could prefab this on the floor and then just put it up ... maybe, I don't know, I'm not a bricklayer.
Well, from the same article: »All a worker as (sic) to do is load the bricks into the machine in the desired pattern and gravity does the hard work«
So it is a more ergonomic way of laying bricks; you're doing it upright, not crouched down. But you still have to lay them. You can't just throw a pile of bricks into it and get a road out without workers doing anything.
There are many, many "bricklayers" out there who actually end up not laying the wall at all. They work hard for weeks perhaps months but eventually give up, sometimes leaving a half-finished wall that is so shoddy it needs tearing down by a more experienced professional before they can put up a better wall.
They may well have been paid in part already for work and you're left with nothing to show for it. In many cases they'll leave and find a new "victim" to work for.
Yes, there are quite a few construction contractors who require they be paid an amount before they begin work. They then either don't even show up, do an awful, intentionally half-finished job, or simply quit to never be heard from again. While anecdotal evidence, my father has been doing construction contracting for the last 17 years and runs into these types of people regularly. He often comes in and finishes the jobs that these people ran from. Usually, he just tears it apart and re-starts.
There are (in the software world) far more instances of bosses who hire you to build a brick wall without the money to do so and put you on net 60 hoping they'll somehow come up with the money by the end.
The more likely scenario in software is you get to day 45 with 90% of the wall built and the client asks you to hand over your key to the job site and stops taking your calls.
There's where most of the "half built walls" in my industry come.
I own a company that works with a number of contractors. I can confirm: this is a huge deal. The fly-by-night subcontractor is a thing. In construction there is nothing more valuable than a network of dependable skilled tradesman. General contractors will pay for good help.
I always thought "if this software thing doesn't work out, I'm gonna go be an electrician". I've now met lots of them making way more money than I am (and I'm well paid). Most of them basically have two or three customers, all of which are GC's. They've shown that they are:
- responsible (show up on time and in the right place)
- dependable (they get the work done on time and on budget)
- knowledgeable (they keep up to date with changes to code)
- respectful (they keep the job-site clean and work well with other subs)
In short, they're professionals in every sense of the word. In exchange they charge 3x what other tradesman charge. People are happy to pay it.
A friend of mine is an electrician. He did his apprenticeship with a guy who worked a lot with high end residential clients (i.e. stately homes — this was in England). He says the one of the most important things that he learned was to clean up after himself — which talks to your respectful point. It made him stand out amongst his peers, and is one of the factors that goes a long way towards repeat business and referrals.
> In construction there is nothing more valuable than a network of dependable skilled tradesman. General contractors will pay for good help.
Being a software developer who just completed a substantial project (200 metres squared house on a difficult site) this was the most powerful thing I learned on the job. And now I apply it to my own code related problems. Who's in my crew? Where can I get new good crew? How do I manage dealing with cognitive overload by delegating back to other team members etc. I find the similarities/differences between software and construction crews fascinating.
I can attest to this. It's ridiculous how unreliable most contractors and tradesmen are. Our house is about 25 years old so we often need to have a bit of work done to fix things and we are often looking for various contractors and I honestly can say that about half of them never show up after agreeing to do the job. Some of them won't even answer their phone and others will try to reschedule indefinitely and still never show up.
I totally wouldn't have a problem paying top dollar for someone who is reliable and respectful of my time.
You're wrong though, you wouldn't prefer to hire B. A will quote you $2000, $500 up-front maybe, and B will quote you $2000, $500 up-front maybe. When you realize B is talking about two hours of work, there is no way you will ever work with him. You will prefer to find some cheap shoddy solution you can supervise for two weeks. It's just how people operate.
There's pretty easy proof of this. You would spend weeks of time, $8000 in recruiting expenses, trying to get a web marketing manager who can increase your conversion rate.
But if there is a web site that you could allow to A/B test some change to your layout - that its operator somehow comes up with very quickly or even programmatically - you would not give them $5000 for a few minutes of work. It doesn't matter what the 'results' are, or if it's in escrow or tied to the results: you just wouldn't. You would prefer to spend weeks of time and double the money on a web marketer who doesn't work as well.
And for that reason, such sites just don't exist.
There is no place on the Internet you can pay someone $10K for 20 minutes of work, even if those 20 minutes are objectively quantifiably better than the results you would otherwise spend 6 months and $100K trying to achieve.
It takes time to learn these things. Maybe after hiring A's for a dozen jobs, it will slowly dawn on you that the value they provide for your money is low, and there's always rework and cost overruns involved. At that point, if someone you know recommends a B to you, you'd be open to trying them.
I don't think your proof works. If you spend $8000 and several weeks recruiting a marketing manager, you're paying for someone who knows what to do and how to do it, because you don't know how and/or don't have time.
If you go to a web site that does A/B testing, you're going to get a set of instructions about how to install it on your site, and then it's up to you to figure out what changes you should try. You now how more work to do, and no better idea about what you should be trying.
If you really do have a way to replace a full-time marketing person with an automated web site, build it. It will be a gold mine.
I'm not saying that there isn't a person out there who can revolutionize my marketing in 20 minutes. I'm saying that I have no way of evaluating someone's marketing skill in just 20 minutes. That's why it's expensive and time-consuming.
If a web site charged $500 and was very easy to implement, I could do it as an experiment and not lose much if it failed. If it succeeded, that web site could charge me again and again to keep doing it, and I would be happy to pay.
But if I have to spend $8000 and several weeks up front, I'm going to be very cautious. It doesn't matter if that money and time are spent hiring someone or purchasing and installing an automated tool.
Note that I defined/proved the non-existence of a market at $5000 (in exchange for 20 minutes of any operator's personal time) and you countered by claiming a (possible) willingness to pay at $500. Thus proving my point. It doesn't really matter what reason you gave, which in your case was trust. Ordinarily that could be countered with escrow or a lack of up-front payment, but this still does not happen, that market still doesn't exist. You can't pay someone whatever revolutionizing your marketing is worth, after you've given them a chance to do so in just 20 minutes and seen, "yep, that works". Doing so would feel wrong to you.
"I'm not saying that there isn't a person out there who can revolutionize my marketing in 20 minutes" - I'm saying you wouldn't pay them to do so in line with what doing so would/should be 'worth' to you. There is no market to pay to revolutionize your marketing in 20 minutes, at a pricing that is based on what it should be worth for you to do so. Doesn't exist. You wouldn't pay it. Imagine what "revolutionaizing your marketing" means, image what "revolutionizing your marketing" would be worth to you - do you have that figure in mind? Now imagine paying that to someone for 20 minutes of their time. You wouldn't. Neither would anyone else. That market doesn't exist.
I completely agree with your conclusion that almost everyone would like to hire Bricklayer B, but I think the disconnect in most work situations comes in rewarding the value provided by that person. If for example both workers would charge 5000 dollars to build the wall, people would be much more skeptical of paying Bricklayer B, because after all, it was only two hours of work. Basically people still have trouble evaluating the value of the work done vs the effort expended to do that work.
It depends - if everyone knew that B would provide a superior wall, in less time, for the same money, then they'd have a choice to make. Do I care about the build quality? Do I care about the time?
A better example is if A now comes back and says "yes, my wall's not as good, and I take longer, but now I'm only going to charge $4000", then you've got a bigger question - is it worth $1000 to you to get a higher quality wall that's done quicker? Or would you rather save the money and lose the time and build quality?
This more easily converts to a software example - do you pay a senior developer to develop your product quickly and well? Or do you save money by hiring a developer of lower skill, who will likely take longer and deliver a lower-quality product?
You're making a key assumption that a person is capable of evaluating the skill of a developer and the quality of the end-result.
What if you have no background in software? If the lower-skill developer convinces you his work is better (even if it's not) you're going to go with him.
"if everyone knew that B would provide a superior wall, in less time, for the same money, then they'd have a choice to make"
I'm more inclined to think that people would try to bargain hard with the Bricklayer B - "$500 in two hours is a good price for you, pal". After all the thought goes that even for that price B can erect a lot of walls in two weeks (which is A's single wall building time-span), and that's... only fair, right?
(in addition) Don't foul yourself that we live only under market-like laws of supply and demand, we're also social creatures that supposedly have to obey social norms. And the norms can be dictated.
I beg to differ, Bricklayer B would reject the job on account of being too busy doing work that paid a sum reflecting the value provided rather than reflecting the sociopathy of the employer.
Or.. B demands a higher payout. That reduces his customer base without affecting his revenue significantly. With fewer customers he has more free time on his hands, in which he invents robots that build brick walls. He now lowers his hourly rate.
I think the point missed is that you can easily look at the work done and contrast the quality of Bricklayer A's and Bricklayer B's. Concrete results will always be easy to verify and contrast immediately whereas the nebulous and vague world of software will really only show its true colors when you're ten years down the road and still able to add enhancements without crippling the system.
Unless you've got x-ray vision, it can be pretty difficult to verify the quality of work. Is there a proper footing under that wall? Is there gravel under that? Was the mortar mixed to the proper consistency? Is there a second course of brick hidden behind the first one (wait, should there be?) and if so what's the quality of that? That's just what I can think to ask from having had one minor wall built. I'm sure a real bricklayer could do better.
Most corporate managers would observe B's rate and demand it of all bricklayers, without bothering to figure out why B built such a good wall. They'd hire cheaply (cost-cutting, HR says this is as much budget as we get) and end up with a bunch of A-type bricklayers, require B-esque timeframes from these A-type people (without bothering to train them in whatever made B so much more efficient) and get terrible walls built by mediocre bricklayers in 2 hours. That is what would actually happen.
And then while they are employing 50 of these brick-layers and notice that their brick structures aren't being built fast enough, they will question bricklayer B again about why even though the walls aren't going up fast enough he's going home at 5 while all of the other bricklayers are going home at 9.
Disagree. First, comparison is not correct, if wall could be built in 2 hours that's not a real product, even hackathons require day or more to build "semi-demo-product". I recommend you watching "Simple made Easy" by Rich Hickey. You could select easy way and do it faster, but eventually your solution will be broken. If task was sorting 10 numbers(static numbers),
you have 3 options
- do it manually
- write small program(everything in main())
- design some architecture for APIs and do sorting
which one do you prefer? your comparison is like so.
P.S. I am not native speaker sorry for mistakes.
The challenge is that it's very hard to understand 1 versus 2. It is very easy to measure energy level and hours. Just look around, and listen.
In software, it is very hard to measure productivity. Lines of code doesn't work. Function points? Nah.... Who is building whose contributions? Many of the nice things (reliability, ease of maintenance, flexibility, ease of testing) that require design expertise take years to see. Add to this that it is very hard to deeply understand complexity of problems, and if the source is the problem itself or the environment.
In the end, maybe the immediate manager knows all that's required, but if you get several layers up in the management chain, eventually you hit a non-technical boss. Unless you're at a software firm with a programmer-CEO. This is why it is important for technical folks to also be good communicators, and to "Work up" well.
I have been "bricklayer B" in this hypothetical scenario when working at a large corporation with a terrible boss.
"Bricklayer A" was constantly rewarded for working hard. I was constantly reprimanded for wasting my time since I was deemed to have a much larger "potential," despite producing more output and with a higher quality than most others on my team.
This ended up with my leaving that team. So I can't agree that "bricklayer B" is always preferred, but I would say that a good manager would usually prefer that choice. Good managers are not easy to find.
I think the GP's point is exactly that: With a physical contractor, you want it done, to spec, as quickly as possible. Anyone can tell that B is a better bricklayer than A, because we can see that the same work got done, but more efficiently, and are happy because we had to pay them less.
With software, it's hard for people to tell that the finished product for Team B is as good as (or better than) that made by Team A, and therefore all they can look at is often effort. They see team A responding to alerts, alarms, production issues, etc, all night and weekend, and then see you cruise out at 5.
I think a software developer is more like a carpenter (and sysadmins are like plumbers, and electricians are like devops etc). I assisted in laying a 150m2 hardwood floor from a 40 year old warehouse earlier this year. There were quite a few invisible processes that were required to get the floor right. And it wasn't clear at the start that the job would be successful. But because of a very skilled carpenter, and my dedication in doing lots of prep work for him (cleaning, grading and flipping the boards) we got a result that cost the same as new boards[1] and looks amazing, and will last another half a century at least.
[1] only because I got the boards for wholesale price.
Neither software nor architecture are easy to understand.
The wall example is similar to "Write a simple calculator capable of doing addition, substraction, division and multiplication". Anyone can tell if that software works as expected or not and have some idea if it's well done or not.
A similar comparison would be a team designing and building a fully functional house on a budget. In that example it's not easy at all to assert how well they are working, as happens in software development.
There is more to bricklaying than shacking bricks. Go look at old structures. You'll see some in Rome where the bricks are still standing 2000 years later. Now look at a typical American patio that cracks in four years and starts to shift. Most people just see bricks, but there are many other factors that will determine if the wall stands the test of time.
This may be true, and while I am no archeologist, the summer I spent digging up Roman stuff disagrees. Their style of bricks, more like tiles, is very strong. I'd guess it relates to the ratio of tile to mortar.
I don't see how that disagrees substantially. If there was substantial variation in projects (intentional or unintentional), both could easily be the case.
Pre 1940s brickwork is all pretty great in my opinion. I have way too many recycled bricks, for paths and gardens. Some are in place, others waiting to be used. They look great and often have names, places etc stamped into them. The brickwork on Edwardian houses, above doors and windows for example, is great. All the angles and precise corners. And all done with hand tools. The best bit is that they wear in. A bit of grime and weather and they look even better. Compared to modern bricks which fall apart when the surface fails or turn out to be made of concrete, old bricks are fantastic. Bricks are another of my strange obsessions. I'll go back to my corner now...
Please don't go back to your corner. If you can, put up a few web pages about bricks. I think the world could use them. I live in a newly built house (+-6 years) and we have a fake brick facade plastered to the front of our house. I have been thinking recently: "Why didn't we just use real bricks in the first place!?!"
I remember a surprisingly interesting website on nails (and I think screws too) and the defects in them from manufacturing problems. The guy was an expert on the manufacturing process. Your giving me ideas now. The ends of bricks on our house (which is as basic as a 1940s house gets, no fancy brickwork here unfortunately) have finger prints in them. I stumbled across some at a demolition yard with the owner cleaning up a load that were apparently made by prisoners a long time ago - a special triangular symbol was stamped into them. That's when the obsession started. Just picked up a few nice ones with a giant W stamped into them which would never normally be seen as its on the top where the mortar goes. The building was demolished in the Christchurch earthquake, so its got that bit of history as well.
It's not all roses pre-1940. I live in a house built in 1880. Some of the brick used in the foundation is of pretty low quality. So much so that their cores seem to be nothing more than compacted brick dust.
There was an article that mentioned ancient roman concrete survived so long not because it was STRONGER (it's about 10 times weaker than modern concrete) but because it survived the elements better. At least partially, because it was made with volcanic ash. I'd bet the same, or a similar, circumstance is the case with the bricks.
Indeed, the post is about crappy management and little else. This is the real story - we talk about scarcity of engineers but it's as nothing compared to the scarcity of effective technical management, which is an industry scandal IMO.
I had a VP once who decreed that the "Productivity" rating on our annual review was to based on the average hours/week spent at work. To be deemed "Productive", a developer had to average 45+ hours/week. This had the effect of screwing over two subsets of developers:
1 - Those that were very efficient and got their work done in a reasonable amount of time.
2 - Those that didn't spend hours/week on timetracking, and just stuck on 40/week by default
And rewarded those who were inefficient and took 50 hours to do 40 hours worth of work.
Sounds like you do all (or most so that you always have something light to finish off the day) of your work when your mind is rested, you are energized and focused, then read and participate in online communities like HN for the rest of the time. It should always be about the work that is done, but I think the big challenge most of the time is how do you measure the work that is done in certain businesses/industries.
Non-bricklayers can make relatively accurate comparisons between two wall-building projects. Non-programmers, and even programmers themselves often cannot do the same thing between two software projects. Managers have the awkward job of having to divvy up work and guess that they've given everyone an equivalent workload. And there's really no way to know for sure.
"Non-bricklayers can make relatively accurate comparisons between two wall-building projects. "
I would dispute the 'relatively accurate' assumption. My father works in construction and it's often the case that what me (as a non-construction worker) sees as a beautiful kitchen, he'll see as a nice-looking kitchen that's been cheaply made with quality and craftsmanship problems.
I would imagine that a bricklayer has a better chance of telling you whether a wall is likely to start cracking within five years than your average person off the street would, for example. You're assuming that non-bricklayers would know what to look for to assess the quality of the wall properly or that brick walls are so simple that any untrained person off the street could figure out what all those hidden factors are.
I think this is actually the exact same thinking mistake that people make when they assume that programming must be easy. It's seeing only what's on the surface and not realising there are deeper things (a previous poster mentioned 'hidden processes' when talking about laying down a hardwood floor, which is exactly what I mean here).
Hmm. I feel misunderstood. Let me try to cut across what we're both talking about and see if we end up at the same place:
Brick walls have a very high level of observability. A non-bricklayer can look at a wall and tell if it fills the space it is supposed to fill, if the wall is obviously crooked or warped, if bricks are missing, and if mortar is missing between bricks. They can do all of this with very little expertise because they can physically inspect the wall and they have also seen many walls before and have internalized some norms for walls.
Compare this with a non-programmer's experience with software. All they see is the user interface, which is usually a very small part of the whole. Software has a very low level of observability.
Brick walls - typically - are also very simple systems when compared to software such as what is described in the original article. Lower complexity combined with a high level of visibility and broadly shared expectations means that lay people can make many more accurate judgements about a wall, the progress of a wall, the quality of work being done on a wall, etc. without being experts on wall building or brick laying.
This is not to take away from expert tradespeople or diminish their value. It's just a completely different situation which I believe was the intent of the original analogy.
One complexity I struggle with is developing potential. Say 'B' is really talented, but also spends a ton of time doing seemingly-unrelated stuff. Maybe chatting with friends on IRC, reading fantasy and gaming blogs, watching YouTube, etc. is part of how the they end up getting work done. But I also think about how maybe just a little less of that could result in them becoming a top performer, because they have the talent and could apply it a little more. Though I completely get that people need "down" time in this business, I've also seen people become exceptional with a little coaching about planning/focusing and time management. The topic of how much time is spent on "other" stuff is often very difficult to discuss in a way that doesn't come off as reprimanding.
> finally builds a brick wall of passable quality [... vs ...] builds a wall of excellent quality.
That is the problem. They can't see it that clearly. Everyone can see a brick wall. "Seeing" good code and from bad is not easy. So another proxy is used -- "apparent effort and time put into it".
So in reality when it comes to software, bricklayer A wins quite often.
Like the article said:
People huddled over screen debugging dangling pointer == GOOD.
Staying Friday night debugging deadlocks in threaded code == GOOD.
Lots of lines of code written == GOOD.
Get stuff done quicker, and then going home on time == BAD.
This is a failure of management, having not insight or understanding into how programming or product works and judging complex machinery and structure by the color of its blinking lights on the console or by the length of haircut of it creator.
An example of the building kind: When I bought my house, the first thing we did was knock down the wall separating the front and back living room. We got a cheap estimate, based on the fact that the wall was just a stud wall - it had been knocked through in the past.
Then I got a panicked call from the builders:
Apparently the previous owner (most like, based on some other horrors) had taking out all the brickwork, without putting in a steel joist to hold the hundreds of kilos of brick of the wall on the floor above in place.
The person who had done that work in the first place might very well have seemed very efficient to someone who didn't know the details. To someone who did understood fully what the job entailed, and knew what to look for, once it was out in the open again, the job was obviously not done in a safe manner at all.
But once the stud wall was in place, it was not apparent that there was a problem. First when it was gone and the builders stared up at brick where they expected a steel joist was it obvious the job was violating regulations and was inherently unsafe.
In software, we do the equivalent of leaving hundreds of kilos of brick unsupported all the time, and cover it up with other layers of code, to the point where it is often extremely hard for anyone to determine quality without going back and auditing every line of code and running every little piece through extensive QA.
It might be a failure of management. But often this is because of woefully lacking resources - clients, whether internal or external, often don't understand the importance and refuses to pay for proper management as well as proper testing, qa and documentation. And this is allowed to continue because often it is "good enough" - just like my wall didn't wall down until the new builders had gotten a steel joist in, so often software projects survive horrific decisions or lack of attention to detail.
If you've ever watched a stone mason work, the tallented ones exert much less effort. My example comes from bar tending. I used to work for a high end catering company so I poured a lot of champaign. After a while, I could pour a bottle into 6 flutes and each flute would be exactly the same height. They would never foam over and it was really easy.
I think the big difference is that people know that pouring six flutes of champaign perfectly is hard. They've poured champaign before and they know they couldn't do it. The same goes for laying a wall. Shit, I don't know any management types that would even do thier own drywall. They know they'd screw it up. But, these same people just assume that software is easy. I just had an interview where the CEO asked me to figure out how to scrape an ugly website. I was given an hour to determine which toolkit to use, learn how to use it, and deliver a solution.
I'm not sure at all here. Basically because if it takes A two weeks what it takes B two hours. Either A totally doesn't get it all, or B is just plainly cheating in some way.
Contrary to whatever you may think, you will not be able to build the next Microsoft, send a probe to mars, invent the next cancer drug, build a formula one car, or build the Pyramid of Giza or anything of such class working 2 hours a day, while relaxing away your time at a beach.
The world is full of examples of a Bill Gates sleeping below his office desk, Michelangelo falling from painting his way to exhaustion, or a John Carmack spending his time hacking in some isolated hotel.
The stories super successful people who work exceptionally hard and very real and are a common place in our culture.
I agree about quality and all that, but none of that will be sufficient for great tasks with meagerly efforts. Great things demand great effort.
I'm yet to hear of successful people who have become what they are by working just 2 hrs a day. Unless they just had a wild date with luck.
The parent comment is not saying that B is working just two hours per day. Rather that B finished the task in two hours (and then likely moved on to do something else).
I have by the way directly witnessed such a huge A vs. B difference in software development. It was in fact two months to two hours ratio. And yet, the A team or the management did not realize this, or even accept this after the fact.
Well 2 hours compared to 2 months(Compared to original 2 week comparison) is an insane level of difference in quality and productivity. So huge that its either really true or some body is cheating or something is at a miss here.
I am not sure why such people even remain programmers all their life. If you can achieve in hours what people take months to achieve, you should be doing very special things. Chase some really big goals. Because after all by the same logic you can achieve in an year what many people may take many lifetimes to achieve.
Why are such people stuck doing some small time programming tasks.
I recall an analogy from Skiena [1], although this is not exactly what happened in my two-month to two-hour example. Skiena talks about a problem which appears to have exponential complexity at first, but then shows an insight that turns it into polynomial time. Consider the potential impact of this. Team Exp will be spending lots more time optimizing, debugging, writing test cases, while the team Poly will go though all of that much faster since the task is much easier now. Not just the running time is different, the development and maintenance time could be different by an order of magnitude too.
In the actual case, the team Months could not connect the dots to see that the specific problem at hand, that involved two complex things, somehow had a much simpler solution. Their code, development time, etc. looked perfectly normal from an outsider's point of view. The code was taking 40 minutes per run. I was unaware of their work and coded the same thing independently. My code was five lines core in Matlab plus overheads, or about hundred lines total. It also ran in two minutes.
In short, no one was cheating. Nothing was amiss. Just that I could connect the dots and they could not. Had I not worked on the problem, I would not have figured either.
The issue is that in the normal course of lives, two people or teams are not asked to work on the same problem in isolation. So the difference in performance does not become evident at least in the short run. This is in spite of the amount of duplication of effort that often exists.
Now this does not imply that I could do this for every task, though I do have more examples just as profound. I can often understand complex problems better and faster than other people, and then can work through them faster. But if both sides understand the problem+solution equally well, I may actually be slower in implementing at least in the initial rounds. (This is because my breadth of knowledge across technology domains is often five-ten times broader than normal engineers, which also implies that I have less practice in each domain).
I've always thought it's the other way around. The success stories are about people who are ruthless about succeeding, who are unable to make a work/life balance because they are motivated to succeed at all costs. The crazy hours are a symptom of what makes them successful, but not the cause of it.
What about the bricklayer who would spend 1 week thinking about a better way to build wall, and two more weeks to tune concrete formula and concrete wall casting? He would eventually raise the wall in half a day, but he'd be one week late, wouldn't he?
This is not just a problem in the programmer domain, though it may be exacberated by how divorced much of management and executive types are from the work of programming. Other domains in which performance is more easily measured by eyeballing, office politics and plain poor perception can still be a factor. At one place I was an intern, before I got formally hired, everyone told me that I was a sure bet to be hired, because everyone thought I worked so hard...when in reality, and I can say this now, I wasn't as focused back then as I am now, and so they were basing their perception about how early I showed up and how late (by late, I mean, maybe 7pm on days when I was really distracted and didn't do enough work during the actual day) I stayed...but not on how much I actually produced.
God forbid one ends up working for a boss who insists you put in 8 hours of sitting time in front of a computer, irrespective of productivity. I worked for one such person in my previous company, I have since quit, working elsewhere where all they care for are the results.
I'm productive in the mornings. I wake up at 5 am and usually work a few hours even before I get to the office. I'm usually ahead of schedule on most tasks. However, this manager felt I was setting a bad example and still felt I should keep a strict schedule and put in 8 hours of "face time". His loss.
It seems the key issue here is that management can often not tell the difference between 'fighting fires' because of incompetence, vs doing it because the problem space is just very, very difficult.
I feel that the situation proposed in the article is a completely false dichotomy. It's a myth that a good team sits in a meeting room for 4 days and codes a perfect product in one swoop on Friday. At the same time, paying someone in KLOCs is probably a guarantee that you'll have a bad time.
This is an issue I struggle with on a regular basis, as we outsource a lot of our development work. We work on a project basis, but work very closely with our partners to help them make good estimates, maximize capacity, and minimize their (and thus our) risk. I don't want people to work overtime, nor do I want them under-committing.
My experience is that watching someone's commits, even from far away, is actually a damn good indicator as to how capacity is being managed on a project. Every project is different, but coders code: if they're not committing frequently and regularly, it's time to check in.
Human beings normally don't have flat productivity, so activity spikes are normal. But low activity in a period means there is not enough work and/or there will be a large spike later, which for me means risk.
Even if what they commit does not solve the customer's problem?
I'd rather have a coder spend 3 days thinking and 10 minutes coding with one commit than spend ten minutes thinking and three days coding with 300 commits.
Coder productivity to me is "is the user of the software more effective in their job?"
Yes, the end goal and final judgement of success is to have your fix/change implemented in the best way for the price you are willing to pay for it... of course.
I'm just saying that in my experience good work actually looks and feels like work, in terms of commits and deliverables. If it looks like nothing is happening, it probably isn't.
Overtime as it was mentioned in the article, on the other hand, is a very untrustworthy indicator of quality work. Managers too easily think that it's a sign of aggressiveness, commitment, perfect capacity estimates (cost savings), etc. But it can just as easily be a sign of bad planning, resource issues, inept management, internal politics, etc.
Managers have to answer the question: is my development team being used most effectively? They need some indicators. Looking at the commits and deliverables isn't perfect, but it's much better than looking at the number of hours someone is sitting in their chair, or ensuring they are adequately stressed out.
This type of question doesn't just apply to programmers.
In IT departments, the ones that seem crazy busy and dealing with all sorts of fires can hint at a deeper issue of low technical ceilings. The IT departments where things seem calm, relaxed, and under control can hint at a higher technical ceiling present.
Similarly, in programming, there are those who are solution based thinkers (assume they understand what the problem is and off they go coding) and are easily caught into a perpetual cycle of refactoring much earlier. There are also developers who take the time to learn the problem from the ground up, by doing the actual work and finding the things that the user is seeking to solve but can't express or imply.
This industrial age thinking of being at a desk for x hours or looking busy is an incredibly poor measuring stick for what is an abstract, and creative pursuit. I find my time away from the keyboard is as important as the time I spend at a keyboard solving problems that need to be thought about.
Going for a walk, helping someone else with their problem before my own all seem to have interesting triggers for creativity -- solving a problem eloquently enough that it requires deep understanding but little programming wizardry.
My favourite part of this article was being open to, and appreciating the value of learning solid processes from someone with more experience of having a relationship with a code base for more than 1-3 years. There are too many times where problems are trivialized, and lessons are re-learnt over and over by new team members, experienced or not.
In the end, I read a quote about the kind of software development environment that I always want to help enable -- avoid wizardry in code, frameworks and technology, and instead focus the creativity and magic on architecture solutions that don't require as much complexity to create the same solution much simpler in the short term and the long run.
Can you talk about what you mean by technical ceiling, and high/low technical ceiling? I've heard the ideas in your last paragraph referred to as the 'rule of least cleverness', avoiding wizardry always good imo.
1) When someone wants to hire a web developer, I say, make sure they don't just know how to do things limited to a few ways. You will inevitably run into needing to do things that you did not expect and don't want to be beyond the technical skills of who you hire, so hiring someone with barely enough skills to put together a Wordpress site using the admin only will certainly not be able to code/modify much of anything custom you might need.
If you hire someone with a higher technical ceiling, who has more skills than what you need at the moment (knows more/knows that they can learn what they need), they will be better positioned to not only grow with you, but give insights instead of just saying yes to everything.
2) Let's say there was a time where the only way to do Windows Updates was manually, by hand on each computer.
Companies would hire someone to come in, once a month, to perform updates on each computer. Service Providers would spring up, providing windows update servicing, which could be relatively taught to anyone. They might have a minimum of technical skills, but they could follow along to a certain point. The ability of the service provider to grow, now was limited to how many windows update patchers they could hire, train, and retain, which over time, meant, hiring less and less technically skilled people to do the work to grow the business as much as possible.
The result? The IT company's had demand for windows updating, which it wanted to grow, and now you had to find people who could do this, and keep doing it reliably so the business could grow. Windows updates become it's low technical ceiling, and it became integral to their business to keep customers dependant on hiring them every month to do it because it's about the limit of what most of their techs could do. Ask those people to solve something else? Too many will try to fake it till they make it.
A high technical ceiling? The IT company that might do it a few times, recognize it to be a very bad use of their time, instead offer to teach the customer how to do it for themselves, and request that they instead invest the saved money in IT services that might help the business more directly, and be a part of learning things with them.
The tricky part of all this? Realizing how much more skill than you need to hire.
What this person describes is basically par for the course in non-IT businesses, especially large ones with multiple teams.
In these organizations the visibility of a team is at least as important as what they do. Managers at these places typically are more interested in playing the political games than attempting to do the "hard" work of managing. One component of those games is to insure that these managers' managers can see their teams working, in the tangible, physical sense. The more "work" being done, the better.
There are 2 ways to evaluate something else: with data or with perceptions. Almost everyone judges by perceptions. Unfortunately this is not limited to middle school cafeterias, single bars, or amateur hours. Some of the biggest culprits are the people you would least expect it from: founders, managers, entrepreneurs, users, and customers.
The is one sure-fire antedote to this: data. And the best data is a precise project plan, with every detail, and always up to date.
I lost track long ago of the instances someone "important" accused me or someone on my team of "not working hard enough" or "not appearing to be doing enough". My response is always the same: whip a current hard copy of the project plan out of my back pocket, throw it onto the desk, and ask the same question, "OK, exactly what is the problem?" This shuts them up every time. They may not like it, but they always STFU.
"Bill not moving fast enough for you? He's responsible for ORP560. 2 weeks ahead of schedule."
"Sue not here enough? She's in Wichita this week. Just implemented RESERVES. Already saved us $200,000."
"Don't like how Gary talks to the customer? Here are 14 examples (right here on the page) where the customer was wrong and Gary straightened them out. How would you suggest he handles it?"
I can go on and on. Many of us skinny introverted geeks have had to find a way to counter the slings and arrows of ugly decision-making by perception with a hacker's solution: maintain the data to counter the perception. It's the best thing that I've ever found that actually works.
This is about people trying to throw their weight around to get/maintain respect, and you're not giving it to them. They may have to STFU in the face of data, but they will probably resent you for it.
FWIW, Google tried to avoid this scenario with 'snippets' which everyone was supposed to do every day. Basically you posted a snippet of what you were thinking about / working on that day which gave folks evaluating you some idea of what was going on in your head at any given time. (note that snippets were world readable)
Unfortunately, when I was there, there wasn't a lot of protection from the conflict created by your snippets, so if you wrote "tried again to convince team X to let me fix their code, they brought up objection a, b, c. Still no clarity from them on what they really want." In your snippet it would make Team X look bad, and at some point it could come back to them that you were bitching about them in your snippets (even if you were doing what you were told to do) and then they would counter-attack in their snippets, and a little sub-surface adhominem would go on for a while. Moderating your snippets made you look non-productive. It was an epic failure in leadership.
No, Google uses the OKR (Objectives and Key Results) system to track performance. You set goals with measurable results, and you grade them every quarter.
That way you aren't evaluated so much on when/how you work, but on what you accomplish.
(I should also include a note here about how you are evaluated by your peers at Google, which has its own set of benefits and downsides, but OKRs are meant to be a somewhat objective measure of output)
I remember dealing with both OKRs and snippets at Google. Personally the snippets were very helpful just helping me keep track of myself. I never ran into the issues the GP did which do sound unfortunate :(
> Everything about your post is correct except the "No,"
My first thought when reading this was that I would have nodded in agreement 90% of the time no matter what the remaining content of the parent had been.
The "no" was directed at this statement, which I believe to be not very accurate:
> Google tried to avoid this scenario with 'snippets'
My point is that OKRs are meant to be used for tracking performance (such as what the article was talking about) and snippets are more for personal use or casually for information among teammates or other curious people who want to know what you work on.
Not sure why you're getting voted down (your comment has gone grey as I type this). I don't recall the OKR system being there when I was (at least not in any sort of formal capacity). The author of the submitted piece was talking about the perception of productivity however, and that was something snippets were designed to provide (at least that was how they were presented to me)
Ah, I've always used snippets more for personal use, so when the time comes to evaluate yourself you have a record. Yes, they are public, but they've always felt more informational than a mandatory log of what you've done.
Ideally you'd be evaluated on the progress you made on both sets of goals with consideration given to the fact that you weren't working on either set of goals for the entire quarter.
I can't imagine a manager who helped you set quarterly goals with objective completion measurements and then penalized you if the goals changed partway through.
There would probably be some discussion as to why the goals needed to change. If they were not set appropriately to begin with that might be an issues between you and your manager or might be an issue between him and his manager (maybe priorities weren't communicated effectively from higher up the chain) or it might truly be a case of changed priorities in the company (changing markets, change financial outlook, whatever).
>>You set goals with measurable results, and you grade them every quarter.
This unfortunately has never worked. I don't if it worked at Google. But as far as I remember 'Setting goals' by and large works like premature optimization or at most in the theme of water fall model.
When we used that approach we found half way down the goal timeline, our priorities as dictated by the business totally changed. We discovered better ways of doing things which altered goals. Some times we found we were simply measuring the wrong things. Some higher priority stuff just preempts the existing business goals and tend to get abandoned etc etc.
I can see how it may work for business folks. Having targets like 'Increase revenue by $100 million', or 'Hire 10 new team members'. But in the grass root level day to day life can hardly be lived in the scopes of rigid goals.
Gaming "Objectives and Key Results" type evaluations is far older than Google. It's not remotely an objective measure unless you have an organization that has extensive knowledge of how to accurately assess effort based on set objectives.
From what I've seen, many organizations that try to formalize evaluations this way are easier to game, because the very idea that there are somewhat reliable metrics makes it easier to justify not following up as closely.
(I'm not saying it will happen, but I've seen it far more often than I care to; including once having a manager that didn't even inquire about what my team had done lately for three years - I didn't mind, I delivered what I should to other parts of the business, but he should have: he had no effective oversight over a team officially reporting to him that handled tens of millions in revenue; if I had messed up, his head would've been on the chopping block next to mine)
This is likely the case but there's absolutely no excuse for a manager to draw a paycheck without at least asking what you're doing. If things seem to be going well and you trust the team, perhaps that's an infrequent high-level "what we did, what we're thinking about next” email but you should know at least that much.
A few years ago, I worked about a small consulting firm that did the same thing. It was exactly as you described it. I would get in trouble for not writing enough, then I'd get in trouble for writing too much. Could never win. Eventually found out people were not only bitching about me, so I setup a daily search for my own name to keep on top of it. Started discovering key work information within their status reports that they weren't sharing with me, too. A year and a half there was 18 months too long.
I don't see how this solves the problem at all. I suppose it gives a "paper trail" that shows what you're working on each day.
But my experience is that this sort of thing (as you observe) really rewards those who are good at writing and navigating the social waters... rather than really reflecting work. If a manager is reviewing snippets, you just need to say what he wants to hear.
Even if it should be "Was kind of blah today, didn't get any work done, talked to Y about it for a while but still didn't do much", you'd of course write "Faced several challenges with X, but made progress; had meeting with Y and got useful feedback".
It's sort of an art, especially when it comes to full performance reviews. I used to be something of a savant on the subject.
I have yet to see ANY system which comes close to measuring programmer productivity, even in a relative way, that isn't prone to huge errors or gaming.
Same problem with interviewing, really; often social adeptness is what's being measured.
To be clear, I didn't say it solved the problem :-) I said Google tried to solve it. My experience of it was that it did have a bit of a 'motivating' effect (which is to say you felt bad if your snippet was 'read docs all day and am still confused', and it did have a bit of keeping track of things feel. But being self created, it varied a lot from engineer to engineer how the snippets read. And yes, it did test both social adeptness to some extent.
It's horrid if you use it to judge or justify, it's actually not so bad if it's something you use to record and analyze without judgment.
That's to say if you do it personally for the purpose of self-improvement, it's fine, when there's a social aspect of trying to determine who is pulling their weight it's going to more dishonest.
> That's to say if you do it personally for the purpose of self-improvement, it's fine,
Exactly. If hundreds of thousands of salary and tens of thousands of bonus dollars are tied to it, there is no doubt judging, gaming and justifying will be going on.
I found the snippets helpful personally, in that I had a log of what I'd been working on at any given week (when I was there, they were weekly not daily). I don't think I was ever judged, at least not to my knowledge, about what I put in the snippets - they were informational, not evaluative. Pretty pleasant overall.
Oh, I know you didn't - you were, pretty obviously, criticizing it.
I see it as a pretty common thing to do though... either on annual basis (as a performance review) or a daily one (as a standup). Granted the theory of the standup is nothing to do with measuring productivity, but it gets noticed.
That sounds like it can be a good personal motivator if it's done privately, though.
It brings to mind what I do when I am having problems with my focus. I keep something like a "ship's log" of my time. I just note the time of day when I start doing something and then the time when my concentration breaks. Next to it I write what I was doing. Now I have a record of what I did, something like
1543-1555 fooled around on Hacker News
1555-1602 bathroom
1602-1619 worked on presentation
1620-1643 worked on presentation
and so on. So I can look back and see that my focus wasn't very good- I 'came out of it' after just a few minutes. And in the same way that forcing myself to log what I eat helps my diet, after a few things like that above I find the discipline to keep persevering when my attention starts to wane.
I think when we wear many hats we're susceptible to unproductive states of mind, and this little hack helps me a lot.
But I don't think it would be a good idea for public display. Depending on the boss, maybe it would be ok if s/he looked at it, but I dunno. I've never had a boss I didn't completely trust, but I think I'm pretty lucky that way.
Maybe snippets would work if they were just between a manager and his or her reports.
Never had a boss you did not completely trust? NEVER? I'd say you're beyond pretty lucky and into extraordinarily fortunate, and congratulations to you. I've only had two bosses I completely trusted, and one of them is myself. And now that I think of it, I don't even completely trust myself.
I have a spreadsheet I use now and again to log in a similar way to what you do, but I additionally classify the time into work/personal/study/procrastination etc., and which charts the time breakdown.
Occasionally I will run it for a day, or even up to a week, check the breakdown, and pick goals to improve on, run it another week etc.
Running it all the time is too time consuming in itself, but occasional "checkpoints" help ensuring I maintain good habits etc.
Would never show it to my boss though - I feel confidentiality for those kinds of things are necessary to ensure you're absolutely honest with yourself. I'd happily recommend people working for me do the same, including withholding it from me.
I do this on my private google calendar when I'm in the zone. It works wonders. What gets measured gets managed. (I can only speak for self-management, I'm completely unqualified to talk about managing others)
Automates it all and self-games so you can set your own targets to beat.
The best part is that you actually think twice about going to that non-productive site because you know it's going to be staring back at you at the end of week report. Of course it takes discipline but sometimes little tools help.
I've been doing something kinda similar for a long time, more like a work diary than a ship's log. I don't write down times or non-work things I'm doing, but I do keep a running log of everything I work on, including what part I'm working on, what I'm trying to get it to do, what solutions I'm trying, thoughts on them, any appropriate bug IDs, changeset IDs, etc. It's meant to be for my eyes only, so no worries about not offending anybody with what I really think of their code or appearing to be sufficiently productive to management or other such things.
I find it very useful for stuff like reminding myself what I was working on yesterday, last week, etc, what I was doing on it and why, and that sort of thing. Being able to search for class names, bug IDs, and changeset IDs is pretty handy too for getting more insight into why I did something, even if it was a while ago. I think it helps keep me more productive too, since I don't want to have to look back on what I did yesterday and only see a couple of sentences.
On one project I did that, very previse reporting. The customer wasn't happy about it, wondering if I was bullshiting him.
At another customer's there was a time reporting software. But instead of reporting real time, we were instructed to report normalized times over an 8-hour work day.
A few years ago I was working on a long-ish project and was tracking my time for billing. I noticed that, every so often, I would total up time spent on this or that feature or behavior and wonder how in the world did that take so long?
So I wrote a small CLI tool that would let me write a short note and append it to a file. The note would be time-stamped, and the file name (or something) would reflect my current working directory.
I forget exactly the details (I should go find this code if I can) but the idea was to be able to record quick observations about what I was doing so that later I could go back and get a more nuanced picture than basic time-tracking might offer.
For example, I could do this:
james:~/dev/BigProject$@ gem docs for stupid-easy-attachment gem do not match reality
The '@' was the name of my note script.
I'd then have a record of my trouble getting some gem to work.
If nothing else it was therapeutic. Sometimes just writing something out spurred a useful idea, too.
My time-tracking tool (JotBot) did allow for adding notes to recorded time but being able to record quick thoughts with little interruption to my work flow was a big win.
I had this same idea back when Yammer was started. But I wanted the social network to match the org chart. Your tweets go to your team. Your boss retweets a subset to his boss and other managers. And so on up to the CEO. This would solve your unfortunate problem and it wouldn't overwhelm people with zillions of irrelevant tweets.
I don't think snippets are really related to this particular problem.
Ultimately, at Google, the results are what matter: Did you implement a system to do something? Are people using it?
In that case, both teams demonstrated look fine: people are able to provision analog and digital channels. If the digital team is doing the same work with a smaller team, then that just makes the team look like they might be working at a higher level, which is good at promotion time.
Once upon a time, early in my career, I spent half a day automating and error-proofing a 15 minute task. My boss, at the time, was slightly annoyed, and slightly amused. Fast forward two months from that point, and that same task needs to be done not once, but several thousand times. My boss wanted to go get coffee before we got started, so while he was grabbing his wallet, I fired up my automated process. By the time we got back, the task was done, and the boss was annoyed at himself for being annoyed earlier, and never again questioned why I built the systems I did. I, unfortunately, was too young and too inexperienced to realize that he was an excellent boss, and left a couple years later for "greener pastures", where I encountered many "productivity is measured entirely by the time you sit at your desk" bosses.
TL;DR: I work hard to look this lazy, had a boss that recognized it, and was too dumb to realize how good I had it.
It could be that you prematurely optimized the task and then got lucky that the optimization turned out to be necessary later on. Your story reads as if you are saying that you were correct to automate the task because later you happened to need the automation, despite not having any reason to believe that automation would be needed. ie. Buying a lottery ticket was perfectly reasonable because I happened to win.
That being said, based on the numbers given, the optimization would make sense as long as you knew the task would be needed to be done at least 16 more times, which I imagine was the case. That also assumes there wasn't anything more pressing that needed to be worked on.
Optimizing optimization. Terrific! Complete with extra-verbose mouseover text just to make the point.
Of course, it leaves off a benefits of the particular type of optimizing that is automation, such as (1) reducing errors in task performance, and, admittedly a little more abstractly, (2) the ability to produce new efficiencies you may not have anticipated until you started automating. Kind of like writing a function only to discover that it's re-usable.
Nice chart, but "across five years" is a little unrealistic IMO. You're much more likely to change projects, jobs, etc. before you realize a five-year payoff.
That chart is misleading. Instead of saying "X days", it should actually say "X*24 hours" because there's a big difference between working on something for a day (e.g. 8-10 hours) and working on something for 24 hours.
To be completely honest, it was a bit of getting lucky, and a lot of realizing that if I needed to modify one object in that particular library to satisfy a legal requirement, it was only a matter of time before a decree would come down that the rest need to be changed as well.
My coworker has a rule in our office: if you have to do something for a second time, automate it.
He's been getting us all to follow this, and it has paid off many times. It's not just about whether it pays off for an individual task — it's a mentality you develop as you go into future tasks.
The article kindly submitted here notes, "I would submit that the appearance of hard work is often an indication of failure. Software development often isn’t done well in a pressurised, interrupt driven, environment. It’s often not a good idea to work long hours."
I would submit that this applies to many "professional" occupations. A lawyer has to produce a draft of a brief or of a contract in time to meet a deadline set by the client's schedule, so the work output just has to get done. But the draft brief or draft contract works best to meet the client's needs if it is developed after thought, and being just-plain-busy isn't the same as thinking. "There is no expedient to which a man will not go to avoid the labor of thinking."[1] So, yes, whether you are a manager of programmers, or a manager of lawyers, or a manager of physicians, or of any other kind of professional, you have to know the professional's craft well enough to know what good work looks like, and you have to make sure that the professional has time to think, and usually time to confer with colleagues to get a reality check on the thinking. (The article kindly submitted here gives the example of the author learning from the original coder of a body of code how the code worked. The code was elegant, but it wasn't easy to see the elegance at first glance.)
It sounds like what is needed is a guild of software engineers[0] that can quality review peers.
Throughout this topic there is a thread of "only [talented] software engineers can rate software engineers". So what is needed is an association of talented software engineers.
[0] with apology if you prefer programmer or other term.
Steve McConnell (of Code Complete fame) has posited this idea before. I keep circling back to it in my head, but I can't mentally untangle what, precisely, would be the rating. Would knowing GoF design patterns be the criteria? How about ability to use Monads? What about being able to accurately describe red-black tree uses? Perhaps a key dividing line would be the ability to spot bugs in a code review? Basically, what would the minimal body of knowledge be to be an accredited guild (union, professional org, etc) member?
The IEEE has built what they call a software engineering body of knowledge. I think it's mostly academic bosh. Am I ignorant for not understanding their reasoning? Who builds the first criteria for what a body of knowledge should be? Having read academic SW engineering publications, I'm convinced that academia does not have the total answer.
I'm convinced that, theoretically, there should be a professional organization, and an interview should be a conversation about people skills + a credential check. But I am - today - not sure how to bootstrap such a thing. If something comes along that I think embodies what is really important (both industrial and academic rigor), I will likely leap on that bandwagon and chug the kool-aid.
I think the problem with such a credentialing body is that within 5 years, the regulatory capture it would experience would make it perverse and useless.
Just because you have a technical, or ex-technical, person in charge of your team doesn't mean it's going to be well managed. I'm sure that's something we've all seen. Every reason that is true will apply to the guild, in addition to the usual ugly prejudice, artificial supply constriction, and self-destructive conservatism that all real guilds, associations, and unions display.
These things already exist, and are universally a failure.
The top people don't need to join, because they are well known and have reputation. The people that do want to join are those who need the trimmings of an endorsement. So gradually it turns into a grouping of people slightly below average trying to improve themselves. Plus, the people who are attracted to this type of thing work in industries where others are bedazzled by credentialism, like academia and government. A group of people dominated by academics and public servants telling me how good they are? Thanks, I'll pass.
I don't know that I'd rush to call all unions and professional organizations a failure. Certainly, say, the AMA or the NSPE has a certain usefulness (if you disagree with that, I don't think we have a common ground to talk about this, I am afraid). But I do agree that structural questions about a credentialing/professional organization do exist and have not been adequately resolved in the sw development field.
Sorry, I wasn't aware that you had confined your comment to our industry. I am in quite definite agreement with you that extant credentialing efforts don't appear to have been successful. I don't think they are intrinsically doomed to failure, however. Suppose that an organization was constructed by professionals from industry organizations who buy into the idea of a credential recognizing competence (as has been done, for instance, in the non-virtual engineering field in the form of the PE). What specifically would be the problem there in your eyes?
I'd put forward the proposition that not only is there no need to measure productivity of developers, but that this is a counterproductive management approach.
1. You have hyperproductive developers (the famous 10x ones). Everybody knows who they are and you can hire or retain them if you provide the correct incentives.
2. Then you have the disaster zones - again they are easily recognisable.
3. With everybody else, _they are going to be as productive as they are going to be_. They will be trying their hardest as much as they can - if they didn't actually want to build software they would be in the disaster zone category. You can improve this via a process of facilitation using well-known approaches to improving the working environment (plenty of info in books like Peopleware for example). As a manager, your biggest problem is stopping them working too hard and burning out because your schedules will become increasingly erratic, and the effect of late hours is always a net loss over the longer term.
If your development team isn't effective, it's a management problem, not a developer one.
A lawyer has to produce a draft of a brief or of a contract in time to meet a deadline set by the client's schedule, so the work output just has to get done. But the draft brief or draft contract works best to meet the client's needs if it is developed after thought, and being just-plain-busy isn't the same as thinking.
Right, but this goes back to a point higher up in this thread.
If Lawyer A writes the contract from scratch every time and takes two days, but Lawyer B has a modular contract-assembly system she optimised earlier and just needs to make a few tweaks -- which will take two hours -- which lawyer will you pick?
That human nature thing again: we'd distrust the person who can get it done too quickly. (Though, we might be able to grok the situation enough to appreciate B's initiative and, especially if we wanted a lot of contracts, might be able to override our instinctive reaction that she hasn't had enough time to think about it properly.)
I've worked in a Dilbert mill or two where managers mistake movement for progress. The thing is, if you aren't ready to quit, then you must play the game. And by that I mean play some actual games. Like Call of Duty or Halo or something. Just come in to the office on some nights and weekends, get your frags in, yet still look like you are "working hard and sacrificing" like the bozos who are only there because they can't design/program well. :-)
After reading this story, it's remarkable how much it reminds me of my own experience. I worked for Amazon.com as an intern for 3 months, then at the end I wasn't offered the position. They said that I showed "excellent technical skill," but they didn't feel that I embodied an Amazon.com employee. One specific criticism was that "For some of the interns, it was difficult to get them to stop working and go home. Not so for [me]."
I figured out the system mostly independently, because the senior developers were always under fire due to the over-large workload for our team. So while other interns would need help for an hour or two every few days, I'd ask something about the data type of a certain value in a function and be on my way. My mentor was especially impressed, but he was the only one because nobody else saw how much code I was writing or its quality. They would just see me getting up to pace about when the problem was very difficult, or opening up hn when I needed to give my brain a break.
Long story short, my manager said that they weren't going to hire me full time, which came as a shock because I thought that producing quality code to the deadline was the important part. He cited early mistakes in writing documentation (I'd never written a functional spec before the internship, but I posit what I eventually produced was of the highest quality) and my perceived lack of motivation. This despite me working as well and energetically as I ever had. I decided to look at it through a lens of another article I'd read on HN: Any company that doesn't want to hire me is a company I probably don't want to work for.
So while I'm dismayed that this pattern will continue, it's nice to know that there are some people who know the difference between a good programmer and one who puts in overlong hours.
That's awful. I would expect more from Amazon. I guess they've decided that, in absence of looking at your actual work, they have to find other metrics by which to measure your performance -- like how many minutes per day your butt is in your seat. What a faulty metric. I'm sorry you wasted your time there, but just know that they'll get the programmers they deserve, and 95% of the places out there will appreciate the qualities you describe.
I'm convinced that "playing the game" and "office politics" are much more about being seen to be working hard (or the illusion of it) than actually getting stuff done well.
Even if you can churn out more quality output in 4 hours than your peers can in 8, you better make sure you're seen to be working hard for those entire 8 hours, and make sure to continually mention to everyone possible just how hard you are working at all times.
This isn't necessary. Just notify your immediate manager every time you hit a milestone (e.g. complete a piece of assigned work), and notify them every time you've run out of work.
Part of the issue with the perception of developer effort seems to be the fact that the developers aren't communicating their success to the manager. The manager sees the failures (admittedly he fails to recognise them as failures), because they're working late and looking stressed. The manager doesn't see the successes, because he fails to understand what success looks like.
The solution isn't to emulate a failure, the solution is to educate the manager (through gentle notifications of work done) as to what success looks like.
An internship is a fit assessment that goes both ways. You and Amazon mutually agreed that it wasn't a good fit (Amazon wanted someone that worked silly hours, and you didn't want to work somewhere which measures you by hours worked). Congratulations on a successful internship.
From what I've read of Amazon, this kind of stuff happens on some teams and not others? It sounds like the balkanization of their product teams create wildly different expectations for employees?
I think that's absolutely the truth with me. My team was smaller by Amazon standards, but the role of the team was such that a very large number of responsibilities fell under their scope. I wasn't involved in much of the other stuff, but the full time employees were working very long hours just to keep up with their "normal" duties. I would meet with other interns for drinks after work, and their stories were much different than mine. Stuff like taking a few hours to drink w/ coworkers and brainstorm patents. My team members rarely engaged in any of the office social life simply because the expectations were so much higher.
This probably varies greatly team-by-team. After all, it's a big company. I interned at Amazon over the summer, too, and basically did the same thing you did. However, I did get a return offer at the end. Sounds like you were unlucky and had a bad experience with your team, and I'm sorry about that. But I will say that what makes the difference probably is communication. You were probably working enthusiastically and producing great code, but did your manager know that? Meanwhile, I wasn't so enthusiastic about my intern project (it was an accounting system, so yawn...), and I didn't really produce all that much code (it was mainly just gluing some existing systems together). Hell, for a whole week, I was blocked waiting for information from a team in India and spent the entire week working on a side project. However, my team had daily standup, and I always had something to say about what I was doing at the time and what I was stuck on. Perhaps you actually were good about communicating what you were doing and your manager just ascribed to the "time of butt in chair" method of measuring programmer productivity, which is unfortunate. But if you didn't, it's something to think about.
Dan Ariely tells the story of a novice locksmith who discovered that as he got better (and was able to open locks much more quickly, with less effort), his customers increasingly resented his fees.
Customers/managers value the perception of hard work, even when the result is measurably worse for them. In fact, we all do this.
I've read comments here some years ago that told it's common for a locksmith to fool around the lock for few minutes with lockpicks and only then grab the gun-like device that does the job 99% of the time - because if they start with the gun, people don't want to pay for what is essentially a 30-second fix.
So what is to be learned here? Well, make the core of your application VERY robust (with good design principles) and have the 'peripheral' modules designed as as 'balls of mud'.
That way you have a good foundation on top which with a front end that is weak which will leave you sweating just enough for management to think you're working hard, all the while the core functionality is never undermined ... !
Working for a less experienced team leader than me, I think this is basically an experience / competence thing. My team leader constantly suggests a quick hack to fix things, and is always talking about "firefighting", as does the article. I often resist, or refuse to do things the way he suggests, taking half a day longer to write a solution that I expect to work a month later.
Looking around for a new job at the moment, it seems hard to convince people that I am worth double what a junior developer will cost. Half of the interviews seem to have the programming language trivia questions. Even if they did ask me more high level design questions, its not the way I work. When I have to design a database, I don't do it in 20mminutes. I usually come up with two or three alternative designs, with pros and cons. I probably look unproductive staring into space, but I take a day or two for big decisions, and mull over the possible scenarios and which design is better. My code is better than it was a few year back.
331 comments
[ 3.3 ms ] story [ 285 ms ] threadEdit: To be fair, my comment relates more to the title than to the body of the post.
Do you think that if you worked nights and weekends (say another 20 hours a week) your total productivity would be diminished vs. your normal week because those extra hours aren't productive?
Yes, but it depends on what type of work is required.
In creative work: if I don't get enough sleep, enough exercise, enough relaxation time, my personal productivity falls to at most a quarter of normal. Total productivity is surely less.
In grunt/repetitive work: my productivity is affected a little but probably not enough to decrease total productivity, and I've noticed my work is appreciated more because I appear to be more 'busy'.
Of course, you could rightfully question whether this is actually increasing the company's productivity or whether they are just so flushed with billions of oil dollars that they can afford to pay their engineers full-time salaries for slightly less than full-time hours.
Source: I worked for one of the majors w/ this policy.
Maybe his case is not normal?
Edit: Granted, I think another reason for this is that, based on his descriptions, there's a remarkable amount of bureaucracy involved in the oil companies. It's a very, very complex industry, and while it moves quite fast on a global scale, it moves very slowly for most individuals involved in it. His training program alone lasts a few years, so he won't really be a highly productive member of the company for quite some time.
It will however put the kibosh on your plans to extract more value from your employees by working them to the bone.
Read Peopleware if you haven't already. It covers myths like the 60 hour work week and outlines how to make software projects productive and predictable.
Can have negative productivity. I am all in favor of keeping work loads light, but in real businesses edge cases come up.
We recently just got through a couple of really harrowing sprints because of such an edge case - a lot of hours were worked. Quality remained high. I personally am satisfied with what we delivered - while it could have been done better with more time, the tradeoffs were all understood and accepted.
The flip side of that is that this kind of thing happens to a given team here maybe once or twice a year. The rest of the time is sane, normal working hours and load. If it were like this a significant portion of the time, then you'd start seeing the kind of patterns you're describing.
The programmer I want/to be is the one who gets shit done the whole time without working nights and weekends and actually spends time doing other things that also matter like family, friends. This way, he/she stays sane and more valuable.
Are you paying them 50% more than market for working for you an additional 50% hours?
People willing to work a 60+ hour week are relatively rare. If you genuinely need that over the long-term, you have to pay for this rarity: in addition to the extra hours.
I agree with you, but not on a single task.
If you want to hire someone who can program for a couple of hours, design your marketing material for a few more, work on your IT infrastructure for another couple of hours, and then maybe go off and do some sales work and meet with the rest of your team, you might have something that works.
Of course, if you find someone who can do all those things well, they are probably off working on their own business and couldn't care less about what you are doing.
At least, as a programmer, I know that having to switch into other modes really diminishes my ability to focus on the problem I'm solving (programming).
Your day sounds like a way to turn a 40-hour programming project into a 80+ hour project.
Now in the real world, where people expect you to do just one thing, I often do multiple two, possibly three, hour stints, with context switches in between each. However, I feel a lot better on the days when I'm able to do different tasks on each switch rather than coming back to the same task each time. You, naturally, still have to give that task your undivided focus while you are working on it. Trying to manage everything at the exact same time will definitely lead to what you suggest.
Of course there are no hard rules. If, for example, you're having a good programming day, maybe you'll put in four straight hours before you feel the need to stop. It is not like you have to put your metaphorical pencil down as soon as the clock strikes the two hour mark.
http://devopsangle.com/2012/04/18/what-research-says-about-w...
In comparison I got a lot done when I spent two months working on code 4-6 hours a day including weekends.
I guess the question should be, Are your programmers working primarily to serve your need as a business or are they devoting their effort and time on work that is more aligned with their own ideology (choice of technology and approach).
A few months back I was in Philly talking to a startup founder whose company was at death's door because he kept hiring developers who came in and replaced whatever the last person did because it wasn't what they preferred. This phenomenon is a much bigger problem than the question of whether programmers are working hard or not.
I think it really comes down to perspective, once you learn to view programming as a means to an end, not an end in itself, I think you become more tolerant of what looks like shabby code.
Keeping code in good condition, delivers a large amount of business value over the long term. Shabby code delivers business value short term, but reduce it long term.
Going back to my earlier point, the important thing is for managers to know how to recognize when a developer's effort is aligned with business interest as opposed to simply allowing developers do what serves their own ideology.
I think once you do that, it becomes easy to discuss/address things like technical debt.
I'm by no means an incredible engineer, but I've spent a couple hours a day over the past few months building basic Ruby/RoR apps, and it makes an enormous difference. Of course, I still have a long way to go before I'm able to really estimate anything, but if nothing else I understand why my co-founder would just sit there for hours with a whiteboard and model data. I know that "burnout" is a real thing, especially when you're not overcoming little bugs you've had for a long time. I know the value of getting a second pair of eyeballs on some code. etc.
It's just impossible to understand what you don't understand the technical aspects of what you're trying to do.
If a manager's only metric about how well his line of business is functioning is how much overtime his employees work, then learning to code will not make him any more competent. It's more likely that if the manager learns a little bit about coding, he'll think that everything his team does is easy (since he never tried to implement anything complex). Also he'll be more likely to be an annoying micromanager, since he'll think that he actually understands the complex issues that his team is grappling with.
Yes, in the long term, the shortcut taking programmer's shortcuts will catch up to him (code will break, you can't add more people to work on his code, etc.), but it could be too late for the manager.
The manager that spent a month "learning to code" but never worked on a big project will think he knows the difference, but probably doesn't either.
EDIT: Of course, I do agree with you. It's just worth keeping in mind that perfection can be hard to reach, at least in the conventional manager-evaluates-engineer format.
I can see how it could get out of hand if I started questioning things I don't understand, beating my chest and saying "Don't tell me that, I know how to code," but now at least I can have a discussion with him without everything going over my head. It's difficult to explain how big of a difference that makes.
We've actually had exactly this problem on a team, where our manager had a rudimentary understanding of database design and became very insistent that the team should do things his way. It eventually got to the point where the team would have to spend 2 hours explaining a design decision to the manager, instead of spending 15 minutes to implement it. It was particularly irksome, because the manager would refuse to read any best practices or take any advice, and became defensive about decisions he didn't understand instead of asking them to be explained more clearly.
That said, I think this issue was caused by 10% technical ineptitude and 90% ego.
I was young and needed money badly at the time so I went along with it, but if I ever found myself in a similar scenario again - where some chest beating bozo is telling me how to do my job - I would explain that I'm not the best fit for their work culture and promptly give my resignation notice.
Unless you're desperate for cash or something, don't ever subject yourself to such blatant disrespect. It's a truly soul crushing experience.
Educate founders to entry-level coding skills (or below) and they will have entry-level abilities at estimating project technical scope and difficulty.
This might in part be because the geologist (a) is in our office and doesn't just burst in every two weeks and (b) does at least a little scripting from time to time, while the other one didn't write a line of code in years.
Take the example in the article, where the developer who made a well factored application was "overcomplicating" the code. It's not uncommon for a beginner who understands the means of programming but hasn't been bitten by the results of bad design to make poor decisions for the sake of experience that need to be made up in extra work later.
Having a manager who actively encourages solutions like "Why not just copy the entire method and wrap it in an if statement?", or "Can't we just comment out the existing code that's incompatible with this new feature?" can be demoralizing - if they're in a position to actually make that happen, it's even worse.
Management is really really hard.
If you have no idea what you are doing, you run around, look really busy and that justifies your position.
Shitty companies fire the first guy and keep the second.
-- God(?), Futurama
https://en.wikisource.org/wiki/Tao_Te_Ching_%28Wikisource_tr...
In the meantime, we lost a really good engineer who was thought to be a slacker because he was a quiet guy and wouldn't expose himself too much.
This sociopathic and pathologic behavior is very common in companies run by "business people with ideas" instead of engineers. It's all based on chest beating, who you know and how much of a smooth talker you are. It's like being in high school all over again. Meritocracy is nowhere to be found.
Not every place is like that. But I find it to be the majority.
It's a little sad that pushing for "visibility" is so important, especially in large corporations, but it helps to put yourself in the boss's shoes - how will he/she know you're doing good work unless you blow your own trumpet?
Arguments that a good boss "should just know" certainly have merit, but it's up to each of us to determine whether our own boss fits in that category and emphasize our accomplishments accordingly if we're to be "performance reviwed" with bonus etc depending on that perception.
Edit: s/now/know/
Explaining that you "wrote a unit test suite that has minimized the long-term impact of bugs" or that you architected an elegant solution to a design issue that will help foster extensibility and testability in the long-term will also likely be met with "this guy is blowing smoke up my rear" because there is no way for the manager to verify those claims.
Anecdotal case, I worked with an individual who was labeled as a "trouble maker" who everyone said constantly raised issues that weren't relevant and that didn't do any real work. The individual ended up quitting because they got sick of the work environment. Next release cycle, all of the projects they were a part of began falling apart. The contribution that this person had been making was identifying shortcomings of the requirements, processes, implementations, and verification steps. Nobody could see past their own bias and lack of understanding about what was happening. They just kept getting frustrated (including management) because from their perspective this individual was just "creating more work".
It's taught me to be wary though and "manage upwards" until I feel confident my own direct manager appreciates and recognises my input.
Raising awareness with my manager's manager is harder: still working on that, I suspect and element of "HELLO HERE I AM FIXING STUFF, IT'S QUITE LATE, BEEN DOING IT FOR A WHILE NOW, OK THEN GLAD WE'VE CONFIRMED WE ALL KNOW THIS" is still needed!
We've all heard about the stereotypical manager-perception of "effort invested will be proportional to results delivered!", like the article laments. But this analogy breaks down really quickly.
Let's use an example that's not from software to illustrate the point -- in fact, let's use the author's own example, laying bricks. Who would you rather hire?
-- Bricklayer A: Takes 2 weeks to finish a wall, stays late every day to finish the job, finally builds a brick wall of passable quality.
-- Bricklayer B: Finishes your wall in two hours because he realizes there's a better way to lay your bricks, and builds a wall of excellent quality.
I feel like most people, even managers of non-software folks, would rather hire B. At least, I certainly would.
So I think the premise of the article is wrong. There's something deeper going on, and dismissing it with "managers want to reward hard work, and creatives don't look like they're working hard" is an explanation that is "neat, simple, and wrong" [0].
[0]: http://en.wikiquote.org/wiki/H._L._Mencken
I've experienced management that could only evaluate your productivity based on hours in the office. Now, I generally did pretty well at that one, because I was doing a lot of hours, but if I had to come in late because my apartment flooded he was all grumpy, because the one tool in his toolbelt wasn't working.
Who said that being a good manager was easy? Managers also need to work hard to deserve their high salaries. Lazy managers who can't be bothered to do their jobs properly should be fired.
If he doesn't, then he's probably using some silly and lazy metric like "hours in the office" or "lines of code written per day". If he does, he probably took the time to learn about your job and make a more accurate assesment of your work.
Really, as a programmer you are supposed to know lots of things, learn some more and work hard; but the guy above you cannot be bothered to learn some useful skills in order to asses your work? What kind of logic is that?
A decent manager should make themselves available to the team, but not interfere with the team unless something's going wrong, or appears to be going down the path of 'going wrong'. They should measure the team by their output, and use that to determine whether things are going wrong, or are about to go wrong.
Attempting to measure a team by their process makes the assumption that the manager is capable of understanding both the current process, and the maximally optimal process against which to compare the current process. It's far safer for both the manager and the team for the manager to avoid such endeavours, and instead measure the output itself against the optimal version of the output, because the output should meet business/product goals against which it can be assessed.
One thing that is hard to work around is where the interviewee must demonstrate their skill first hand (e.g. implement FizzBuzz followed by strcpy and a binary search.)
Many common interview questions are too indirect (Show me a certificate; Answer this trivia question about a Java API from 1997) or misguided attempts at personality tests (How many sewing machines are there in West Virginia) all of which one can prepare for without having the actual ability to do the job.
These kinds of questions can still work, as long as they have not yet made it into "How to succeed at interviews" type books. Or when the applicants you want to filter out cannot resist outing themselves even with training (e.g. "Tell me about a time when you have been wrong / publicly changed your opinion" will probably always be a useful filter.)
Bricklaying machines where bricks go into a bucket and out the other end comes a horizontal wall. You could prefab this on the floor and then just put it up ... maybe, I don't know, I'm not a bricklayer.
Seems automated from the article.
Edit: As mentioned below, reading is fundamental, I should learn to do it sometime.
So it is a more ergonomic way of laying bricks; you're doing it upright, not crouched down. But you still have to lay them. You can't just throw a pile of bricks into it and get a road out without workers doing anything.
They may well have been paid in part already for work and you're left with nothing to show for it. In many cases they'll leave and find a new "victim" to work for.
The more likely scenario in software is you get to day 45 with 90% of the wall built and the client asks you to hand over your key to the job site and stops taking your calls.
There's where most of the "half built walls" in my industry come.
I always thought "if this software thing doesn't work out, I'm gonna go be an electrician". I've now met lots of them making way more money than I am (and I'm well paid). Most of them basically have two or three customers, all of which are GC's. They've shown that they are:
- responsible (show up on time and in the right place)
- dependable (they get the work done on time and on budget)
- knowledgeable (they keep up to date with changes to code)
- respectful (they keep the job-site clean and work well with other subs)
In short, they're professionals in every sense of the word. In exchange they charge 3x what other tradesman charge. People are happy to pay it.
A friend of mine is an electrician. He did his apprenticeship with a guy who worked a lot with high end residential clients (i.e. stately homes — this was in England). He says the one of the most important things that he learned was to clean up after himself — which talks to your respectful point. It made him stand out amongst his peers, and is one of the factors that goes a long way towards repeat business and referrals.
1. Physically appearing at job site.
Being a software developer who just completed a substantial project (200 metres squared house on a difficult site) this was the most powerful thing I learned on the job. And now I apply it to my own code related problems. Who's in my crew? Where can I get new good crew? How do I manage dealing with cognitive overload by delegating back to other team members etc. I find the similarities/differences between software and construction crews fascinating.
I totally wouldn't have a problem paying top dollar for someone who is reliable and respectful of my time.
There's pretty easy proof of this. You would spend weeks of time, $8000 in recruiting expenses, trying to get a web marketing manager who can increase your conversion rate.
But if there is a web site that you could allow to A/B test some change to your layout - that its operator somehow comes up with very quickly or even programmatically - you would not give them $5000 for a few minutes of work. It doesn't matter what the 'results' are, or if it's in escrow or tied to the results: you just wouldn't. You would prefer to spend weeks of time and double the money on a web marketer who doesn't work as well.
And for that reason, such sites just don't exist.
There is no place on the Internet you can pay someone $10K for 20 minutes of work, even if those 20 minutes are objectively quantifiably better than the results you would otherwise spend 6 months and $100K trying to achieve.
Human psychology just doesn't operate like that.
Markets can remain irrational longer than B can remain solvent.
If you go to a web site that does A/B testing, you're going to get a set of instructions about how to install it on your site, and then it's up to you to figure out what changes you should try. You now how more work to do, and no better idea about what you should be trying.
If you really do have a way to replace a full-time marketing person with an automated web site, build it. It will be a gold mine.
Think through the pricing model of the hypothetical web site you propose in the last sentence - that is my point.
If a web site charged $500 and was very easy to implement, I could do it as an experiment and not lose much if it failed. If it succeeded, that web site could charge me again and again to keep doing it, and I would be happy to pay.
But if I have to spend $8000 and several weeks up front, I'm going to be very cautious. It doesn't matter if that money and time are spent hiring someone or purchasing and installing an automated tool.
"I'm not saying that there isn't a person out there who can revolutionize my marketing in 20 minutes" - I'm saying you wouldn't pay them to do so in line with what doing so would/should be 'worth' to you. There is no market to pay to revolutionize your marketing in 20 minutes, at a pricing that is based on what it should be worth for you to do so. Doesn't exist. You wouldn't pay it. Imagine what "revolutionaizing your marketing" means, image what "revolutionizing your marketing" would be worth to you - do you have that figure in mind? Now imagine paying that to someone for 20 minutes of their time. You wouldn't. Neither would anyone else. That market doesn't exist.
A better example is if A now comes back and says "yes, my wall's not as good, and I take longer, but now I'm only going to charge $4000", then you've got a bigger question - is it worth $1000 to you to get a higher quality wall that's done quicker? Or would you rather save the money and lose the time and build quality?
This more easily converts to a software example - do you pay a senior developer to develop your product quickly and well? Or do you save money by hiring a developer of lower skill, who will likely take longer and deliver a lower-quality product?
What if you have no background in software? If the lower-skill developer convinces you his work is better (even if it's not) you're going to go with him.
I'm more inclined to think that people would try to bargain hard with the Bricklayer B - "$500 in two hours is a good price for you, pal". After all the thought goes that even for that price B can erect a lot of walls in two weeks (which is A's single wall building time-span), and that's... only fair, right?
(in addition) Don't foul yourself that we live only under market-like laws of supply and demand, we're also social creatures that supposedly have to obey social norms. And the norms can be dictated.
"Unless you can afford to have two or more competing teams solving the same problem, and c’mon, who would do that, you will never know."
So, the above metaphor is almost always impractical, and it's hard to tell what the alternative is to the one bricklayer you have.
The mythical man month never mentioned that. It mentioned multiple implementations of one architecture, but that was for hardware IIRC.
Bricklayer B has an idea that his ideas are better, but they aren't really.
Brick layer B is really bricklayer A.
Sure it isn't simple.
In software, it is very hard to measure productivity. Lines of code doesn't work. Function points? Nah.... Who is building whose contributions? Many of the nice things (reliability, ease of maintenance, flexibility, ease of testing) that require design expertise take years to see. Add to this that it is very hard to deeply understand complexity of problems, and if the source is the problem itself or the environment.
In the end, maybe the immediate manager knows all that's required, but if you get several layers up in the management chain, eventually you hit a non-technical boss. Unless you're at a software firm with a programmer-CEO. This is why it is important for technical folks to also be good communicators, and to "Work up" well.
"Bricklayer A" was constantly rewarded for working hard. I was constantly reprimanded for wasting my time since I was deemed to have a much larger "potential," despite producing more output and with a higher quality than most others on my team.
This ended up with my leaving that team. So I can't agree that "bricklayer B" is always preferred, but I would say that a good manager would usually prefer that choice. Good managers are not easy to find.
With software, it's hard for people to tell that the finished product for Team B is as good as (or better than) that made by Team A, and therefore all they can look at is often effort. They see team A responding to alerts, alarms, production issues, etc, all night and weekend, and then see you cruise out at 5.
Sometimes comparing one piece of software to another piece of software is like comparing a garden shed to a skyscraper.
[1] only because I got the boards for wholesale price.
The wall example is similar to "Write a simple calculator capable of doing addition, substraction, division and multiplication". Anyone can tell if that software works as expected or not and have some idea if it's well done or not.
A similar comparison would be a team designing and building a fully functional house on a budget. In that example it's not easy at all to assert how well they are working, as happens in software development.
Does the software solve your problem? Then it's good software. If not, then what are you paying the programmers for, anyway?
I had a VP once who decreed that the "Productivity" rating on our annual review was to based on the average hours/week spent at work. To be deemed "Productive", a developer had to average 45+ hours/week. This had the effect of screwing over two subsets of developers: 1 - Those that were very efficient and got their work done in a reasonable amount of time. 2 - Those that didn't spend hours/week on timetracking, and just stuck on 40/week by default And rewarded those who were inefficient and took 50 hours to do 40 hours worth of work.
I would dispute the 'relatively accurate' assumption. My father works in construction and it's often the case that what me (as a non-construction worker) sees as a beautiful kitchen, he'll see as a nice-looking kitchen that's been cheaply made with quality and craftsmanship problems.
I would imagine that a bricklayer has a better chance of telling you whether a wall is likely to start cracking within five years than your average person off the street would, for example. You're assuming that non-bricklayers would know what to look for to assess the quality of the wall properly or that brick walls are so simple that any untrained person off the street could figure out what all those hidden factors are.
I think this is actually the exact same thinking mistake that people make when they assume that programming must be easy. It's seeing only what's on the surface and not realising there are deeper things (a previous poster mentioned 'hidden processes' when talking about laying down a hardwood floor, which is exactly what I mean here).
Brick walls have a very high level of observability. A non-bricklayer can look at a wall and tell if it fills the space it is supposed to fill, if the wall is obviously crooked or warped, if bricks are missing, and if mortar is missing between bricks. They can do all of this with very little expertise because they can physically inspect the wall and they have also seen many walls before and have internalized some norms for walls.
Compare this with a non-programmer's experience with software. All they see is the user interface, which is usually a very small part of the whole. Software has a very low level of observability.
Brick walls - typically - are also very simple systems when compared to software such as what is described in the original article. Lower complexity combined with a high level of visibility and broadly shared expectations means that lay people can make many more accurate judgements about a wall, the progress of a wall, the quality of work being done on a wall, etc. without being experts on wall building or brick laying.
This is not to take away from expert tradespeople or diminish their value. It's just a completely different situation which I believe was the intent of the original analogy.
I can think of few businesses where workers don't need downtime.
-- Bricklayer C: Tells you that you don't really need a brick wall, and should just stop heckling the people who go by.
There's even less observable work, and even more savings.
That is the problem. They can't see it that clearly. Everyone can see a brick wall. "Seeing" good code and from bad is not easy. So another proxy is used -- "apparent effort and time put into it".
So in reality when it comes to software, bricklayer A wins quite often.
Like the article said:
People huddled over screen debugging dangling pointer == GOOD.
Staying Friday night debugging deadlocks in threaded code == GOOD.
Lots of lines of code written == GOOD.
Get stuff done quicker, and then going home on time == BAD.
This is a failure of management, having not insight or understanding into how programming or product works and judging complex machinery and structure by the color of its blinking lights on the console or by the length of haircut of it creator.
Then I got a panicked call from the builders:
Apparently the previous owner (most like, based on some other horrors) had taking out all the brickwork, without putting in a steel joist to hold the hundreds of kilos of brick of the wall on the floor above in place.
The person who had done that work in the first place might very well have seemed very efficient to someone who didn't know the details. To someone who did understood fully what the job entailed, and knew what to look for, once it was out in the open again, the job was obviously not done in a safe manner at all.
But once the stud wall was in place, it was not apparent that there was a problem. First when it was gone and the builders stared up at brick where they expected a steel joist was it obvious the job was violating regulations and was inherently unsafe.
In software, we do the equivalent of leaving hundreds of kilos of brick unsupported all the time, and cover it up with other layers of code, to the point where it is often extremely hard for anyone to determine quality without going back and auditing every line of code and running every little piece through extensive QA.
It might be a failure of management. But often this is because of woefully lacking resources - clients, whether internal or external, often don't understand the importance and refuses to pay for proper management as well as proper testing, qa and documentation. And this is allowed to continue because often it is "good enough" - just like my wall didn't wall down until the new builders had gotten a steel joist in, so often software projects survive horrific decisions or lack of attention to detail.
I think the big difference is that people know that pouring six flutes of champaign perfectly is hard. They've poured champaign before and they know they couldn't do it. The same goes for laying a wall. Shit, I don't know any management types that would even do thier own drywall. They know they'd screw it up. But, these same people just assume that software is easy. I just had an interview where the CEO asked me to figure out how to scrape an ugly website. I was given an hour to determine which toolkit to use, learn how to use it, and deliver a solution.
Contrary to whatever you may think, you will not be able to build the next Microsoft, send a probe to mars, invent the next cancer drug, build a formula one car, or build the Pyramid of Giza or anything of such class working 2 hours a day, while relaxing away your time at a beach.
The world is full of examples of a Bill Gates sleeping below his office desk, Michelangelo falling from painting his way to exhaustion, or a John Carmack spending his time hacking in some isolated hotel.
The stories super successful people who work exceptionally hard and very real and are a common place in our culture.
I agree about quality and all that, but none of that will be sufficient for great tasks with meagerly efforts. Great things demand great effort.
I'm yet to hear of successful people who have become what they are by working just 2 hrs a day. Unless they just had a wild date with luck.
I have by the way directly witnessed such a huge A vs. B difference in software development. It was in fact two months to two hours ratio. And yet, the A team or the management did not realize this, or even accept this after the fact.
I am not sure why such people even remain programmers all their life. If you can achieve in hours what people take months to achieve, you should be doing very special things. Chase some really big goals. Because after all by the same logic you can achieve in an year what many people may take many lifetimes to achieve.
Why are such people stuck doing some small time programming tasks.
In the actual case, the team Months could not connect the dots to see that the specific problem at hand, that involved two complex things, somehow had a much simpler solution. Their code, development time, etc. looked perfectly normal from an outsider's point of view. The code was taking 40 minutes per run. I was unaware of their work and coded the same thing independently. My code was five lines core in Matlab plus overheads, or about hundred lines total. It also ran in two minutes.
In short, no one was cheating. Nothing was amiss. Just that I could connect the dots and they could not. Had I not worked on the problem, I would not have figured either.
The issue is that in the normal course of lives, two people or teams are not asked to work on the same problem in isolation. So the difference in performance does not become evident at least in the short run. This is in spite of the amount of duplication of effort that often exists.
Now this does not imply that I could do this for every task, though I do have more examples just as profound. I can often understand complex problems better and faster than other people, and then can work through them faster. But if both sides understand the problem+solution equally well, I may actually be slower in implementing at least in the initial rounds. (This is because my breadth of knowledge across technology domains is often five-ten times broader than normal engineers, which also implies that I have less practice in each domain).
And yes, I am chasing some really big goals.
[1] www.amazon.com/Algorithm-Design-Manual-Steven-Skiena/dp/1848000693/
Needless to say I don't work there any more and I have a good question for when interviewers ask for "any questions?"
This is an issue I struggle with on a regular basis, as we outsource a lot of our development work. We work on a project basis, but work very closely with our partners to help them make good estimates, maximize capacity, and minimize their (and thus our) risk. I don't want people to work overtime, nor do I want them under-committing.
My experience is that watching someone's commits, even from far away, is actually a damn good indicator as to how capacity is being managed on a project. Every project is different, but coders code: if they're not committing frequently and regularly, it's time to check in.
Human beings normally don't have flat productivity, so activity spikes are normal. But low activity in a period means there is not enough work and/or there will be a large spike later, which for me means risk.
I'd rather have a coder spend 3 days thinking and 10 minutes coding with one commit than spend ten minutes thinking and three days coding with 300 commits.
Coder productivity to me is "is the user of the software more effective in their job?"
I'm just saying that in my experience good work actually looks and feels like work, in terms of commits and deliverables. If it looks like nothing is happening, it probably isn't.
Overtime as it was mentioned in the article, on the other hand, is a very untrustworthy indicator of quality work. Managers too easily think that it's a sign of aggressiveness, commitment, perfect capacity estimates (cost savings), etc. But it can just as easily be a sign of bad planning, resource issues, inept management, internal politics, etc.
Managers have to answer the question: is my development team being used most effectively? They need some indicators. Looking at the commits and deliverables isn't perfect, but it's much better than looking at the number of hours someone is sitting in their chair, or ensuring they are adequately stressed out.
In IT departments, the ones that seem crazy busy and dealing with all sorts of fires can hint at a deeper issue of low technical ceilings. The IT departments where things seem calm, relaxed, and under control can hint at a higher technical ceiling present.
Similarly, in programming, there are those who are solution based thinkers (assume they understand what the problem is and off they go coding) and are easily caught into a perpetual cycle of refactoring much earlier. There are also developers who take the time to learn the problem from the ground up, by doing the actual work and finding the things that the user is seeking to solve but can't express or imply.
This industrial age thinking of being at a desk for x hours or looking busy is an incredibly poor measuring stick for what is an abstract, and creative pursuit. I find my time away from the keyboard is as important as the time I spend at a keyboard solving problems that need to be thought about.
Going for a walk, helping someone else with their problem before my own all seem to have interesting triggers for creativity -- solving a problem eloquently enough that it requires deep understanding but little programming wizardry.
My favourite part of this article was being open to, and appreciating the value of learning solid processes from someone with more experience of having a relationship with a code base for more than 1-3 years. There are too many times where problems are trivialized, and lessons are re-learnt over and over by new team members, experienced or not.
In the end, I read a quote about the kind of software development environment that I always want to help enable -- avoid wizardry in code, frameworks and technology, and instead focus the creativity and magic on architecture solutions that don't require as much complexity to create the same solution much simpler in the short term and the long run.
1) When someone wants to hire a web developer, I say, make sure they don't just know how to do things limited to a few ways. You will inevitably run into needing to do things that you did not expect and don't want to be beyond the technical skills of who you hire, so hiring someone with barely enough skills to put together a Wordpress site using the admin only will certainly not be able to code/modify much of anything custom you might need.
If you hire someone with a higher technical ceiling, who has more skills than what you need at the moment (knows more/knows that they can learn what they need), they will be better positioned to not only grow with you, but give insights instead of just saying yes to everything.
2) Let's say there was a time where the only way to do Windows Updates was manually, by hand on each computer.
Companies would hire someone to come in, once a month, to perform updates on each computer. Service Providers would spring up, providing windows update servicing, which could be relatively taught to anyone. They might have a minimum of technical skills, but they could follow along to a certain point. The ability of the service provider to grow, now was limited to how many windows update patchers they could hire, train, and retain, which over time, meant, hiring less and less technically skilled people to do the work to grow the business as much as possible.
The result? The IT company's had demand for windows updating, which it wanted to grow, and now you had to find people who could do this, and keep doing it reliably so the business could grow. Windows updates become it's low technical ceiling, and it became integral to their business to keep customers dependant on hiring them every month to do it because it's about the limit of what most of their techs could do. Ask those people to solve something else? Too many will try to fake it till they make it.
A high technical ceiling? The IT company that might do it a few times, recognize it to be a very bad use of their time, instead offer to teach the customer how to do it for themselves, and request that they instead invest the saved money in IT services that might help the business more directly, and be a part of learning things with them.
The tricky part of all this? Realizing how much more skill than you need to hire.
In these organizations the visibility of a team is at least as important as what they do. Managers at these places typically are more interested in playing the political games than attempting to do the "hard" work of managing. One component of those games is to insure that these managers' managers can see their teams working, in the tangible, physical sense. The more "work" being done, the better.
Managers at these places are awful to work for.
The is one sure-fire antedote to this: data. And the best data is a precise project plan, with every detail, and always up to date.
I lost track long ago of the instances someone "important" accused me or someone on my team of "not working hard enough" or "not appearing to be doing enough". My response is always the same: whip a current hard copy of the project plan out of my back pocket, throw it onto the desk, and ask the same question, "OK, exactly what is the problem?" This shuts them up every time. They may not like it, but they always STFU.
"Bill not moving fast enough for you? He's responsible for ORP560. 2 weeks ahead of schedule."
"Sue not here enough? She's in Wichita this week. Just implemented RESERVES. Already saved us $200,000."
"Don't like how Gary talks to the customer? Here are 14 examples (right here on the page) where the customer was wrong and Gary straightened them out. How would you suggest he handles it?"
I can go on and on. Many of us skinny introverted geeks have had to find a way to counter the slings and arrows of ugly decision-making by perception with a hacker's solution: maintain the data to counter the perception. It's the best thing that I've ever found that actually works.
This is about people trying to throw their weight around to get/maintain respect, and you're not giving it to them. They may have to STFU in the face of data, but they will probably resent you for it.
Unfortunately, when I was there, there wasn't a lot of protection from the conflict created by your snippets, so if you wrote "tried again to convince team X to let me fix their code, they brought up objection a, b, c. Still no clarity from them on what they really want." In your snippet it would make Team X look bad, and at some point it could come back to them that you were bitching about them in your snippets (even if you were doing what you were told to do) and then they would counter-attack in their snippets, and a little sub-surface adhominem would go on for a while. Moderating your snippets made you look non-productive. It was an epic failure in leadership.
That way you aren't evaluated so much on when/how you work, but on what you accomplish.
(I should also include a note here about how you are evaluated by your peers at Google, which has its own set of benefits and downsides, but OKRs are meant to be a somewhat objective measure of output)
My first thought when reading this was that I would have nodded in agreement 90% of the time no matter what the remaining content of the parent had been.
> Google tried to avoid this scenario with 'snippets'
My point is that OKRs are meant to be used for tracking performance (such as what the article was talking about) and snippets are more for personal use or casually for information among teammates or other curious people who want to know what you work on.
I can't imagine a manager who helped you set quarterly goals with objective completion measurements and then penalized you if the goals changed partway through.
There would probably be some discussion as to why the goals needed to change. If they were not set appropriately to begin with that might be an issues between you and your manager or might be an issue between him and his manager (maybe priorities weren't communicated effectively from higher up the chain) or it might truly be a case of changed priorities in the company (changing markets, change financial outlook, whatever).
This unfortunately has never worked. I don't if it worked at Google. But as far as I remember 'Setting goals' by and large works like premature optimization or at most in the theme of water fall model.
When we used that approach we found half way down the goal timeline, our priorities as dictated by the business totally changed. We discovered better ways of doing things which altered goals. Some times we found we were simply measuring the wrong things. Some higher priority stuff just preempts the existing business goals and tend to get abandoned etc etc.
I can see how it may work for business folks. Having targets like 'Increase revenue by $100 million', or 'Hire 10 new team members'. But in the grass root level day to day life can hardly be lived in the scopes of rigid goals.
From what I've seen, many organizations that try to formalize evaluations this way are easier to game, because the very idea that there are somewhat reliable metrics makes it easier to justify not following up as closely.
(I'm not saying it will happen, but I've seen it far more often than I care to; including once having a manager that didn't even inquire about what my team had done lately for three years - I didn't mind, I delivered what I should to other parts of the business, but he should have: he had no effective oversight over a team officially reporting to him that handled tens of millions in revenue; if I had messed up, his head would've been on the chopping block next to mine)
Maybe he trusted you?
But my experience is that this sort of thing (as you observe) really rewards those who are good at writing and navigating the social waters... rather than really reflecting work. If a manager is reviewing snippets, you just need to say what he wants to hear.
Even if it should be "Was kind of blah today, didn't get any work done, talked to Y about it for a while but still didn't do much", you'd of course write "Faced several challenges with X, but made progress; had meeting with Y and got useful feedback".
It's sort of an art, especially when it comes to full performance reviews. I used to be something of a savant on the subject.
I have yet to see ANY system which comes close to measuring programmer productivity, even in a relative way, that isn't prone to huge errors or gaming.
Same problem with interviewing, really; often social adeptness is what's being measured.
That's to say if you do it personally for the purpose of self-improvement, it's fine, when there's a social aspect of trying to determine who is pulling their weight it's going to more dishonest.
Exactly. If hundreds of thousands of salary and tens of thousands of bonus dollars are tied to it, there is no doubt judging, gaming and justifying will be going on.
I see it as a pretty common thing to do though... either on annual basis (as a performance review) or a daily one (as a standup). Granted the theory of the standup is nothing to do with measuring productivity, but it gets noticed.
It brings to mind what I do when I am having problems with my focus. I keep something like a "ship's log" of my time. I just note the time of day when I start doing something and then the time when my concentration breaks. Next to it I write what I was doing. Now I have a record of what I did, something like
and so on. So I can look back and see that my focus wasn't very good- I 'came out of it' after just a few minutes. And in the same way that forcing myself to log what I eat helps my diet, after a few things like that above I find the discipline to keep persevering when my attention starts to wane.I think when we wear many hats we're susceptible to unproductive states of mind, and this little hack helps me a lot.
But I don't think it would be a good idea for public display. Depending on the boss, maybe it would be ok if s/he looked at it, but I dunno. I've never had a boss I didn't completely trust, but I think I'm pretty lucky that way.
Maybe snippets would work if they were just between a manager and his or her reports.
It's a pretty basic strategy - if everyone else is fluffing up their reports, you sure don't want to be the one who isn't.
Occasionally I will run it for a day, or even up to a week, check the breakdown, and pick goals to improve on, run it another week etc.
Running it all the time is too time consuming in itself, but occasional "checkpoints" help ensuring I maintain good habits etc.
Would never show it to my boss though - I feel confidentiality for those kinds of things are necessary to ensure you're absolutely honest with yourself. I'd happily recommend people working for me do the same, including withholding it from me.
Automates it all and self-games so you can set your own targets to beat.
The best part is that you actually think twice about going to that non-productive site because you know it's going to be staring back at you at the end of week report. Of course it takes discipline but sometimes little tools help.
I'm dabbling with quantified self strategies. I want to cover everything.
Health (BP, glucose, etc), food, pills, github commits, potty breaks, phone/chat/email, exercise, and most importantly sleep.
I want the data collection done passively (I will never journal).
I even want the total self app to periodically ask me what my mental state is. "Are you happy?" "Do you have a head ache?" "How does your tummy feel?"
I find it very useful for stuff like reminding myself what I was working on yesterday, last week, etc, what I was doing on it and why, and that sort of thing. Being able to search for class names, bug IDs, and changeset IDs is pretty handy too for getting more insight into why I did something, even if it was a while ago. I think it helps keep me more productive too, since I don't want to have to look back on what I did yesterday and only see a couple of sentences.
At another customer's there was a time reporting software. But instead of reporting real time, we were instructed to report normalized times over an 8-hour work day.
There is no hiding from a pair.
So I wrote a small CLI tool that would let me write a short note and append it to a file. The note would be time-stamped, and the file name (or something) would reflect my current working directory.
I forget exactly the details (I should go find this code if I can) but the idea was to be able to record quick observations about what I was doing so that later I could go back and get a more nuanced picture than basic time-tracking might offer.
For example, I could do this:
The '@' was the name of my note script.I'd then have a record of my trouble getting some gem to work.
If nothing else it was therapeutic. Sometimes just writing something out spurred a useful idea, too.
My time-tracking tool (JotBot) did allow for adding notes to recorded time but being able to record quick thoughts with little interruption to my work flow was a big win.
Adding a hostname and putting the log in a Dropbox directory means you can keep track across PCs easily.
Helps to alias it to something shorter. I use "t".
Ultimately, at Google, the results are what matter: Did you implement a system to do something? Are people using it?
In that case, both teams demonstrated look fine: people are able to provision analog and digital channels. If the digital team is doing the same work with a smaller team, then that just makes the team look like they might be working at a higher level, which is good at promotion time.
Once upon a time, early in my career, I spent half a day automating and error-proofing a 15 minute task. My boss, at the time, was slightly annoyed, and slightly amused. Fast forward two months from that point, and that same task needs to be done not once, but several thousand times. My boss wanted to go get coffee before we got started, so while he was grabbing his wallet, I fired up my automated process. By the time we got back, the task was done, and the boss was annoyed at himself for being annoyed earlier, and never again questioned why I built the systems I did. I, unfortunately, was too young and too inexperienced to realize that he was an excellent boss, and left a couple years later for "greener pastures", where I encountered many "productivity is measured entirely by the time you sit at your desk" bosses.
TL;DR: I work hard to look this lazy, had a boss that recognized it, and was too dumb to realize how good I had it.
That being said, based on the numbers given, the optimization would make sense as long as you knew the task would be needed to be done at least 16 more times, which I imagine was the case. That also assumes there wasn't anything more pressing that needed to be worked on.
http://xkcd.com/1205/
Of course, it leaves off a benefits of the particular type of optimizing that is automation, such as (1) reducing errors in task performance, and, admittedly a little more abstractly, (2) the ability to produce new efficiencies you may not have anticipated until you started automating. Kind of like writing a function only to discover that it's re-usable.
He's been getting us all to follow this, and it has paid off many times. It's not just about whether it pays off for an individual task — it's a mentality you develop as you go into future tasks.
Productivity is measured by both building such systems, and how many such systems you build everyday.
I would submit that this applies to many "professional" occupations. A lawyer has to produce a draft of a brief or of a contract in time to meet a deadline set by the client's schedule, so the work output just has to get done. But the draft brief or draft contract works best to meet the client's needs if it is developed after thought, and being just-plain-busy isn't the same as thinking. "There is no expedient to which a man will not go to avoid the labor of thinking."[1] So, yes, whether you are a manager of programmers, or a manager of lawyers, or a manager of physicians, or of any other kind of professional, you have to know the professional's craft well enough to know what good work looks like, and you have to make sure that the professional has time to think, and usually time to confer with colleagues to get a reality check on the thinking. (The article kindly submitted here gives the example of the author learning from the original coder of a body of code how the code worked. The code was elegant, but it wasn't easy to see the elegance at first glance.)
[1] https://en.wikiquote.org/wiki/Thomas_Edison#Misattributed
Throughout this topic there is a thread of "only [talented] software engineers can rate software engineers". So what is needed is an association of talented software engineers.
[0] with apology if you prefer programmer or other term.
The IEEE has built what they call a software engineering body of knowledge. I think it's mostly academic bosh. Am I ignorant for not understanding their reasoning? Who builds the first criteria for what a body of knowledge should be? Having read academic SW engineering publications, I'm convinced that academia does not have the total answer.
I'm convinced that, theoretically, there should be a professional organization, and an interview should be a conversation about people skills + a credential check. But I am - today - not sure how to bootstrap such a thing. If something comes along that I think embodies what is really important (both industrial and academic rigor), I will likely leap on that bandwagon and chug the kool-aid.
Just because you have a technical, or ex-technical, person in charge of your team doesn't mean it's going to be well managed. I'm sure that's something we've all seen. Every reason that is true will apply to the guild, in addition to the usual ugly prejudice, artificial supply constriction, and self-destructive conservatism that all real guilds, associations, and unions display.
The top people don't need to join, because they are well known and have reputation. The people that do want to join are those who need the trimmings of an endorsement. So gradually it turns into a grouping of people slightly below average trying to improve themselves. Plus, the people who are attracted to this type of thing work in industries where others are bedazzled by credentialism, like academia and government. A group of people dominated by academics and public servants telling me how good they are? Thanks, I'll pass.
Peer review aka open source.
1. You have hyperproductive developers (the famous 10x ones). Everybody knows who they are and you can hire or retain them if you provide the correct incentives.
2. Then you have the disaster zones - again they are easily recognisable.
3. With everybody else, _they are going to be as productive as they are going to be_. They will be trying their hardest as much as they can - if they didn't actually want to build software they would be in the disaster zone category. You can improve this via a process of facilitation using well-known approaches to improving the working environment (plenty of info in books like Peopleware for example). As a manager, your biggest problem is stopping them working too hard and burning out because your schedules will become increasingly erratic, and the effect of late hours is always a net loss over the longer term.
If your development team isn't effective, it's a management problem, not a developer one.
Right, but this goes back to a point higher up in this thread.
If Lawyer A writes the contract from scratch every time and takes two days, but Lawyer B has a modular contract-assembly system she optimised earlier and just needs to make a few tweaks -- which will take two hours -- which lawyer will you pick?
That human nature thing again: we'd distrust the person who can get it done too quickly. (Though, we might be able to grok the situation enough to appreciate B's initiative and, especially if we wanted a lot of contracts, might be able to override our instinctive reaction that she hasn't had enough time to think about it properly.)
I figured out the system mostly independently, because the senior developers were always under fire due to the over-large workload for our team. So while other interns would need help for an hour or two every few days, I'd ask something about the data type of a certain value in a function and be on my way. My mentor was especially impressed, but he was the only one because nobody else saw how much code I was writing or its quality. They would just see me getting up to pace about when the problem was very difficult, or opening up hn when I needed to give my brain a break.
Long story short, my manager said that they weren't going to hire me full time, which came as a shock because I thought that producing quality code to the deadline was the important part. He cited early mistakes in writing documentation (I'd never written a functional spec before the internship, but I posit what I eventually produced was of the highest quality) and my perceived lack of motivation. This despite me working as well and energetically as I ever had. I decided to look at it through a lens of another article I'd read on HN: Any company that doesn't want to hire me is a company I probably don't want to work for.
So while I'm dismayed that this pattern will continue, it's nice to know that there are some people who know the difference between a good programmer and one who puts in overlong hours.
Even if you can churn out more quality output in 4 hours than your peers can in 8, you better make sure you're seen to be working hard for those entire 8 hours, and make sure to continually mention to everyone possible just how hard you are working at all times.
Part of the issue with the perception of developer effort seems to be the fact that the developers aren't communicating their success to the manager. The manager sees the failures (admittedly he fails to recognise them as failures), because they're working late and looking stressed. The manager doesn't see the successes, because he fails to understand what success looks like.
The solution isn't to emulate a failure, the solution is to educate the manager (through gentle notifications of work done) as to what success looks like.
Customers/managers value the perception of hard work, even when the result is measurably worse for them. In fact, we all do this.
Looking around for a new job at the moment, it seems hard to convince people that I am worth double what a junior developer will cost. Half of the interviews seem to have the programming language trivia questions. Even if they did ask me more high level design questions, its not the way I work. When I have to design a database, I don't do it in 20mminutes. I usually come up with two or three alternative designs, with pros and cons. I probably look unproductive staring into space, but I take a day or two for big decisions, and mull over the possible scenarios and which design is better. My code is better than it was a few year back.