That's where the plan falls down. I'd have to partner with someone else that looks good and talks to management while I play the part of the disheveled geek.
So, this sort of devolves to economics, at least where I work. What I mean is, the people that pay for the code don't care and don't care to know. And this is entirely rational from their point of view. If it appears to work, it's good.
To audit the code accurately (as opposed to merely giving out aesthetic advice), in most cases would involve learning the domain, and this is what's expensive.
To the business folks, we're a black box. Stuff goes in, stuff comes out. And it costs. Paying someone else at least as much to prove that we did it according to 'best practice' (I think this is what you're suggesting?) would be anathema.
There might be a business there but it's not mass market.
It's probably also worth noting that all of the above applies to other domains too. Substitute 'code' for 'marketing' quality. In some real senses, die welt ist alles was der fall ist.
> To audit the code accurately (as opposed to merely giving out aesthetic advice), in most cases would involve learning the domain, and this is what's expensive.
There are a lot of things between aesthetics and domain knowledge that are audit-able. A lot of code bases you can walk into and see a million n+1 queries right away and the architectural patterns that lead to them. Another canary is the test complexity that reveals various anti-patterns like active record. Another is correct IOC usage, a lot of code bases will use it for creating POCO objects for example. These are all very common and quickly discoverable.
> So, this sort of devolves to economics, at least where I work. What I mean is, the people that pay for the code don't care and don't care to know. And this is entirely rational from their point of view. If it appears to work, it's good.
I wonder if you could go in and say "this project is costing you $10 million" and we can give you an early indication of whether it's going to be worthwhile or be a turd.
> There are a lot of things between aesthetics and domain
> knowledge that are audit-able.
I don't disagree with you. The pertinent question is 'does anyone care'?
> A lot of code bases you can walk into and see a million
> n+1 queries right away and the architectural patterns
> that lead to them. Another canary is the test
> complexity that reveals various anti-patterns like
> active record. Another is correct IOC usage, a lot of
> code bases will use it for creating POCO objects for
> example. These are all very common and quickly
> discoverable.
Again, I don't disagree. You're right, possibly even corrrect. But we're talking business plans yes? So feel free to buy that expensive suit (or hire a beard) and see if you can explain these issues and why they matter to the people with the money.
"If dogs could talk, perhaps we would find it as hard to get along with them as we do with people."
I get what you mean but I do think the care factor could be broken down a bit better. Some simply don't care, talking to them is a waste of time. Some don't care because the can't, they don't have the visibility into things so they're pointless to worry about.
The final group does care, often because there arse is on the line and are often a CXO. These are the ones that love Agile/scrum because they think it'll identify problems early and/or they don't trust their Devs.
Whether a solid business case could be sold I'm not sure, but I think everyone that ever hired a scrum consultant would be the target market.
Is it really the most important? I'd question that. If you have a guy who writes brilliant code, but isn't on board with the company philosophy, or is acerbic and difficult to work with, or something like that, he won't be as effective as a journeyman better at the non-code aspects of the job.
There is quite simply no way to quantify in a scientific way how "good" a developer is.
Whether or not a developer is "good", and "how good", is purely subjective.
This is the core problem at the heart of all recruiting, and no matter how hard people try to quantify, test, assess and interview, it is still not possible to make an objective statement about how "good" a developer is.
Part of the issue is that "good" depends on a vast array of factors: the task at hand, the developers experience with the specific technologies, how they feel today, who the judge is, if the developer is feeling good or bad today, if the developer is interested in this specific task etc etc etc etc it goes on and on.
And one of the worst traps to fall into is to think that a developers "ability to code" in some way is a really good measure of how good that developer is. i.e. how quickly can you reverse an array, sort of dict of arrays etc. To my mind this is only a certain portion of what goes to make a great developer, and not even necessarily a very large or important portion. So many other things are important in making "a good developer" that assessing substantially on code seems misguided.
Most importantly, "good" to me, is definitely not the same as "good" to you, because the important things for you are likely completely different to the important things to me.
I wrote a post about some of the characteristics of a great software developer, but even this does little to nothing in terms of providing a "science" for the evaluation of how good a programmer is.
The best description for a good programmer that I have ever heard is from Joel Spolsky who suggested to employ people who are "smart and get stuff done". Interestingly, almost no employers take this approach to recruiting.
There is no reliable method yet. But who is to say there won't eventually be one?
You point out there numerous different dimensions of good coding. Consider an IQ test, it has many different categories, but since these strengths are correlated, you can compute an overall "score" for something very abstract like intelligence.
Why should we not, if we dedicate effort, be able to make something similar for coding? Aptitudes are already measured very effectively in many other disciplines (LSATs, MCATS, Putnams, SAT II)
I think this is a great approach but it may backfire in smaller companies. If I have a coworker who is my senior and they ask me to review my code-review with him, I'm not going to rat him out and say he's a terrible coder. I'll say something like "it was really interesting to do a code review with ____. His design choices may not have lined up with mine ideas but the review went well." Or something like that. Maybe I'm alone I don't know.
I'm sure you have company. Amongst that company: people I've fired for doing just this. [unprintable] with my information and you're gone.
The only reason to do this is because you don't have another job lined up where you're allowed to do what you're paid for, yet, but are doing your best to find one.
I sympathize with your plight, but if you can't do the job, you can't keep cashing the checks.
This largely amounts to the question: "How do you tell if someone is extremely conscientious or just puts on a show of being so?"
The best answer is, wait a couple decades. Of course, that's not the answer you want, you want to know now. Close code reviews (plural) may tell. Ratios of kinds of bugs may also be a tell (if they're committing more dumb syntactic mistakes that debuggers easily catch they're probably good, and spending their time preventing ugly and subtle logic errors.)
But to the extent that algorithm choice and design is part of their job, that may not be enough.
>
The risk with this approach is that the criteria are vague from a developer’s point of view. They can’t really know what their manager is thinking. There is now an incentive to focus on learning to sell themselves to their manager instead of focusing on becoming a better developer.
My experience tells me that the best developers are:
- generous with their time to other devs
- not defensive about their code
- able to solve complex problems fast, and explain those solutions to other people
- able to focus really intensely
- enthusiastic about learning new things
- lazy about boring stuff (to the extent that they will spend 4 hours looking for a shortcut that saves them doing 1 hour of boring stuff)
but some of the most productive programmers I've worked with treated the entire thing as a job that they did from 9 to 5 to pay the bills, and their real interest lay elsewhere
and some of the best programmers I've seen were the hardest to manage, and ultimately were a net negative to the team
Coding is creative - there are an infinite number of ways to solve any given problem. This is why it's so hard to predict and manage, and resists quantification.
I second this! From my experience the best or rather most productive programmers get stuff done focusing on customers over eligant code. Mostly, just because they want to get something done so they can either avoid further meetings or work on their personal stuff.
The "best" programmers you mentioned, from my experience, always end up souring the whole team. Most of the time, they can't seem to tell the forest from the trees.
With that in mind, one of the things I tell my team we always need to hire more of are just developers with social skills. Being effective at working with a team is 100x more important than being a good developer. As an example, I have spent weeks in meetings debating archetecture. Each meeting I would make my same suggestions and then the rest of our "best" developers would debate. By the 6th or so meeting regarding the architecture I just presented a prototype of the project. I won the debate by acting, not by trying to find an ideal solution.
I think it is false dichotomy. "Best" programmers at least do nothing before they have a plan and HLD (good or bad). Productive programmers simply get things done both ways, good or bad. I've seen many times how we "productively" produced overengineered unreadable spaghetti that works. Yeah, I can write even straighter single-page perl golf too to show selling prototypes, but that's not what we are paid for as a company. That can be outmanaged by detailed design specification, but then you have to have an expertise at the code level (easy) and spend half time on the task yourself (hard).
Good attitude for startups which will die after barely releasing MVP.
Others will learn that maintaining is where the most time is spent and that chasing customers' whims without any regard how it all fits together will lead you to the situstion where new features are no longer possible to implement and the old ones start to break in random places. But hey, you at least talk about it for hours with all those wonderful social skills you have.
>>Being effective at working with a team is 100x more important than being a good developer.
Having such a constant in your mind would be indicative of never having to do something 'hard' (algorithmic, latency related, extract every single bit of performance b/c you have to)
There are lots of ways to go wrong, of course, but make very sure anyone you hire with high social skills also has high ethics (there's an inverse correlation.) Because a good actor can trash almost any tech business, if they have enough knowledge to pass. The truly competent techies will be outmatched.
When you can't find a clear answer... May be you asking the wrong question.
Create code is - in my opinion - a service, not a product...
If you keep paying a service like it is a product it will continue to be inefficient and open to opportunitistic behaviour.
What about changing the reward model then?
What you, programmer, get paid some fix price for expenses coverage and then a fee for each week (or month) you're software runs without a flaw? Or a fee that goes on as long as software keep working (with your eventual maintenance and fix help, of course).
This would make customer happy (he has a working programmer) and do reward more the best programmers.
The main issue of one-time assessment on programmer job is, in fact, that you not always discover software flaws immediately.. it takes time..
Ultimately, in a business setting, those are the only two metrics that matter.
Selection is a management problem, and like many management problems the median level of understanding is primitive and often dysfunctional.
Not many businesses understand how many flavours developers are available in, nor how to match those flavours to the team/project roles they need at that time. So they robo-hire with standard CS whiteboard hazing, or interview for "cultural fit", or some other nonsense.
The hard-headed hiring question is always "Will this person make the business more money, and if so, how?"
This may sound like a recipe for a sweat shop, but it really isn't. There's a lot of possible variation in "how", which includes making smart architectural choices, having good team lead skills, raising the company profile through social presence, and so on.
The strongest possible code is always a good thing, but sometimes it's fine if it's eclipsed by other qualities. You're hiring a person with many possible skills, not a cog in a machine that you're planning to spin as fast as possible until it breaks.
It's up to management to work out how to get value from that. And there's a lot of creative potential in management that traditional work cultures overlook.
"Will buying this insurance make the business more money, and if so, how?" is a little more nuanced, since it requires consideration of risk, and dependent, unknown factors.
And that is just fine. The idea is to highlight a topic for discussion, which this article did a great job of, as reflected in the discussion in this thread.
Been a coder and engineer for 12+ years, now a manager of a team of 8.
I evaluate my team on their ability to ship regularly and with a consistently low bug count. I encourage communication regularly and pair programming and all that. And I am around and I listen and interact.
It is pretty easy to tell when someone isn't pulling their weight or is having problems contributing based on the interactions within the team. People naturally express frustration (as well as praise)... you just have to be an active, hands on (not micromanaging necessarily) manager.
In addition, I specifically look for growth mentality when hiring and cultivate it within the team. That way I can be confident that when a weakness or need for improvement is identified, the person will work on it. It's my job as manager to properly address it and motivate the person.
In my experience, KPIs and other measurables (including even basic timesheets) are always gamed by developers. And anyway there are so many intangible and abstract aspects to doing this job, especially as you advance in your career, that it's arguable that the most important parts of the work aren't even measurable in any real sense in the first place. That's the art.
In situations where agile/story-points make sense, I suppose developers that accomplish more story-points are "better".
In academia, articles that are referenced more frequently are "more important". For page ranking, pages that are referenced more frequently, are more important. I wonder if there's an equivalent with infrastructure programming? If a developer builds a subsystem that is used frequently, does that indicate the developer has provided substantive value?
You are not the one who choses what subsystem you will work on, If someone writes a mandatory wrapper for logging which then is used in every single subsystem doesn't mean anything. If someone writes the selfdriving algorythm for the car which works on itself but is not used by other subsystems, this means nothing either.
> In situations where agile/story-points make sense, I suppose developers that accomplish more story-points are "better".
Not really. Story points are cost estimates--a subjective judgement of how much effort a story will take. They're a prediction tool, not a productivity measure. It's very easy to increase the # of story points you deliver just by increasing your estimate and possibly even sandbagging. Not good.
If story points were value estimates, created by a business folks rather than developers, they'd be better measures. But even then they'd be subject to gaming. It's easy to increase velocity in the short term by incurring technical debt. Say, not writing enough (or good enough) tests. Or not helping out co-workers. Or not spending time understanding business context. Or...
Simple solution that gets close to the social truth: ask team members to rank everyone else. Average the rankings.
It works surprisingly well and for teams of up to 10 people or so differences in rankings are mostly noise.
That's not the worst thing to do but is game able the same way a lot of the proposed methods are. The developer who brings donuts to morning meetings is likely to score very high on this measure. Also given the diversity challenges a lot of teams have it's possible unconscious (or even overt) prejudices will affect scoring.
It's something to add to the toolbox, and a consistently low score for one person is a sure sign of trouble, but ithe does have some of the same shortcomings the other approaches do.
I would (and expect of my peers too) only value the donut-bringing as a minor strength compared to their technical skills and interactions with me. Which I think makes a little game-ifying ok: If someone wants to make a conscious effort to be the donut guy instead of the never-say-hi-in-the-hallway guy, they've earned a few points.
The amount of points to award is the tricky point, maybe it depends on company culture. How much value does the lovable team player bring, how much value does the awkward quietly-fix-anything person bring?
I've seen peer ranking work well for hiring when people in the team are strong and are motivated to hire even stronger ones.
It doesn't work at all when the team members are not so strong. They tend to value people who don't question "best practices" and don't take bold, unconventional positions. In essence, groupthink wins.
How productive is the developer? That is, how many tasks do they complete successfully over a period of time? The definition of a completed task is something that doesn't have bad bugs that affect the product negatively, and doesn't introduce very much technical debt.
Then, how technically challenging can the task get while the developer maintains the same level of productivity?
I manage a data science team, and currently I measure on 4 axes:
–Technical (ability to effectively solve problems)
–Business (picking which problems to solve)
–Productivity (things done to improve workflows, automate processes, etc. of themselves & team)
–Team (teaching, hiring, training)
This works pretty well. I find that these skills are multiplicative, so someone's impact on the team is reasonably well-approximated by taking an average of these scores. I also find many things you might expect, e.g. variance in technical skill is pretty high, talented engineers usually develop high technical skills before high skills in the other domains, senior engineers tend to be force multipliers by being exceptional at the non-technical skills, etc.
Meh, this is almost exactly the formulaic industry-standard "solution."
The challenge here is that a human is evaluating all of these traits (you). Of course you think you're not biased, but research shows all humans are [e.f. more likely to promote people who remind them of themselves, without being threatening].
I think much like if an engineer made code and said "it's working great" without any kind of external monitoring to validate, asking a manager to promote without external validation is completely a crap-shoot.
I think what you label business is the most important and also hardest skill of these. It is also immediately relevant for productivity and team/training if you consider "learning as a whole"[0] a good approach (which I do).
Back when I worked at Boeing, I was once compared poorly against another engineer who was always down on the factory floor when called, any time, whenever there was a problem with his stuff. The thing was, I was not called down to the factory floor because my stuff worked.
I'd say a developer is doing a good job when you, as a manager, are not having him come in at all hours to fix problems with his stuff.
Other signs of a good developer are you don't have to micromanage him, and he's more of a partner helping you get things done rather than a subordinate you've got to spell things out for and check up on.
I.e. when he's on the job and you can relax and concentrate on other things, you've got a good 'un.
This is exactly the problem with this industry - Blanket statements and buzzwords.
An engineer can get things done quickly but that doesn't mean it's done correctly and won't break (and someone else will have to fix it).
To complicate things more, a feature might seem to work perfectly, until a certain point when you realize that it's all wrong at an architectural level and you have to rewrite everything.
An engineer can get things done quickly but that doesn't mean it's done correctly and won't break (and someone else will have to fix it).
If something doesn't work then it's not done.
To complicate things more, a feature might seem to work perfectly, until a certain point when you realize that it's all wrong at an architectural level and you have to rewrite everything.
If the requirements have changed then a new piece of work is needed. That doesn't invalidate the previous work; it just means things have changed.
There is a difference between something not working and domething prone to breaking in the future.
Changes are fine, but your architecture may be the one that accommodates changes with ease or makes any change extremely painful.
There's a difficult balance between "future-proofing" and "over-engineering". I'm not sure which is actually worse. Given how often I've seen a client happily run a prototype of some code in a production environment for years, I tend to err on the side of thinking future-proofing being a bit of a waste of time. This is especially true if there isn't a clear roadmap that states when something is going to change, and the cost of changing isn't already committed to the project.
IME the best architectural designs are usually the result of heavy retrospective refactoring, not up-front design.
Thus future proofing isn't just a waste of time, it's actively counter productive. The predicted requirements are rarely correct although the extra code remains a liability.
> IME the best architectural designs are usually the result of heavy retrospective refactoring, not up-front design.
Right. And this applies to other disciplines too. "Heavy retrospective refactoring" is exactly what a writer does each time they go back and make edits to a piece. Connections between elements such as characters, themes, writing style, and dialogue are felt out only by emitting draft after draft.
Even this comment went through many edits to get into this shape. These two sentences alone have been rewritten ten times.
In my experience there's also value in imposing a framework once one has done enough emitting of raw material. For code this might be looking for ways to extract common logic out of several similar functions. For writing this might be considering how two characters have "interacted" so far and what other details ought to fill out their relationship (without considering whether or not all those details will manifest overtly in the work.)
This is where experience comes into play though. Not every bit of software is totally unique and built on first principals. If you're working at some place and built similar software at a previous place, part of the up-front design is going to be driven by retrospection on previous projects.
But wait a minute - shouldn't most of one's future-proofing be making sure you CAN easily alter a design later if need be (including better documentation), especially in the ways you can already see change coming?
Cleaning up existing code will make it easier to alter designs later and that's something you should continually be doing as you implement features and fix bugs, but that's not pre-emptive architecture.
As I say elsewhere here, I've killed projects assuming that. Pulling out bricks from the bottom and replacing them is sometimes so hard, you really have a dead project.
There may be, and often are, valid business reasons so that it's more important to get X working now in a way that's prone to breaking in the future, instead of spending more time to do it properly; and that choice is not really up to the developer, often they wouldn't have enough information/context to make an informed decision. A developer who always takes the time to ensure that things are done right is (in most industries) doing suboptimal work by definition, since one shouldn't always do so, it's a tradeoff.
I agree with this sentiment of weighing short vs long terms needs. However, if you are working in a medium to large place not everyone is benevolently doing things just for the sake of the company. Many times managers demand to sacrifice software quality for their own career climbing even if it will be a liability to the company as a whole.
Prisoner's Dilemma. A very real thing in management stuctures - one historical example, middle managers under pressure from the top who cheated on X-Rays testing the work on a silo for a nuclear plant. The big boys didn't know. Killed the plant, and I think, the company.
I once wasted a helluvalot of money obeying just such an order, and not doing the extra coding I knew would prevent inadvertent huge purchase X. Turned out the boss just didn't know how to do complex logic or how to listen, or think ahead. The break, when it inevitably came, was catastrophic, but had the good effect of removing said boss (I was long gone.)
Yup. The CMM of "firefighters" is immature and drama/chaos-oriented. Solid engineering is best when it often goes ubiquitously unnoticed because it just works like a reliable utility (uptime FTW).
> I'd say a developer is doing a good job when you, as a manager, are not having him come in at all hours to fix problems with his stuff.
That's also what a developer who ships nothing, ever, looks like. There are quite a few of those. A developer who gets the most done and tackles the hardest work, on the most important and frequently used tools, integrating with the most problematic 3rd party systems and has specialist knowledge is likely to be called on a lot.
Ultimately you can't make any judgement of the developer without detailed understanding of the specifics of the work. This applies to every possible developer productivity metric which is why its so damned hard.
well remote working does make checking on the remote worker harder so more difficult to know what they are actually doing, but knowing if their tasks are difficult or similar things should be achievable just over chat.
Sadly you are right. In person, an unskilled manager can tell if it looks like you are working hard, even if they don't understand what you are doing. Remotely, they can't even tell that, and are effectively blind.
I have noticed that people who review your code have no issue with remote work, and can easily assess your state of mind, personality traits without much more help like video and visits. It makes it harder for the people not reviewing your work.
If you can't accurately assess the productivity of the developers by monitoring their output, you will default to metrics you can understand - usually that means monitoring the time spent in their seat.
From what I've seen coding managers seem much more open to remote work than non-coding managers.
I've meet one programming manager with 0 programming experience (but he was a Mech Engr). His team loved him, they got real work done, he prioritized things for them effectively, and he helped insulate them from the b.s.
So, while it's rare there are certainly managers out there who can.
You can manage them, you just can't judge their work. I'm a team lead and I'm lucky in that my direct supervisor was a programmer for a long time, still runs a SaaS in his spare time, etc, so he gets it. But he has colleagues who are CPAs, management consultants, etc before they were managing their current dev teams.
They rely a lot more on their technical leads to tell them how the other devs are doing at a technical level. They're perfectly capable of managing their professional development without having an in-depth knowledge of enterprise architecture or C#.
> They rely a lot more on their technical leads to tell them how the other devs are doing at a technical level.
So the leads are de facto managers in that they're assisting the manager in managing the other developers. I think this can work, but I don't think it contradicts what I said. It just means the leads wind up doing some managing even though that's not what their titles say.
At the company I work for we've had a few developers who would've done a lot less damage if they hadn't written any code rather than the code they did write, which we then spent months on to detangle afterwards.
Those are bad enough - but I have met one developer that was technically competent (I would definitely pass his code in a review) except that he didn't care about how anything else worked in the company or even the logical constraints of the real world data (like the concept of brand was useless because different companies providing data treated it so differently) so what he spent a month working on at the end was nice code that did what it was ostensibly supposed to do but that could not be integrated with anything else, as a result of which if that code was integrated it meant the destruction of several years worth of work.
Was he a good developer? Looking at his github repo I would have said yes... talking to him I said yes... if I had examined what he built without any context I would have said yes, but really he was something of a company destroyer that I would not ever recommend to anyone else.
Yes, exactly. There are developers who can create code that works, that looks fine, that works for a certain context; however that context is completely separate from reality.
Conceptual damage to an application is a lot harder to fix than the damage of 'ugly' code. You spend years fully recovering from fundamental flaws in the concepts of your application.
This rings true. There are those who tackle the low level plumbing, core problems and take them on with the rest of the team. Then there are those who take on surface-deep issues. Intentions and subject matters.
I'm considered slow (ish), but I have very few bugs returned. Most (but not all) the faster devs have many bugs (often trivial, but sometimes show stopper) and spend time going back and forth with QA.
My thinking is, QA isn't there to find my bugs. They're there to make sure I don't have any. I seem to be in the minority on that thinking.
I also consider myself on the slower side (I've never objectively measured, but it's how I feel), but I try to not let any errors leave my local environment. Sometimes I wonder if it all depends on how you came up programming. My early jobs were all in finance dealing with money and payroll systems. Mistakes meant people didn't get paid properly, and led to lots of clean up work for everyone involved. This led me to think hard about every change, and multiple ways to test the change.
Even today it would never occur to me to make a change and push without testing said change, although I see people do it all the time.
> Even today it would never occur to me to make a change and push without testing said change, although I see people do it all the time.
How is this even a thing? I don't understand it, yet I come across it time after time.
If you weren't self-educated, did you just throw together assignments without testing them? At work, how can you just write code without testing the functionality.
I've seen people work on webapps that didn't bother to navigate to page they changed. I'd pull in code, go to test my change, and find that the page looks like a GeoCities atrocity. Then I start rolling back changes only to find the code I pulled is the culprit.
I can understand writing a unit test that doesn't cover as well as one thinks. Not taking 15 seconds to visually inspect a visual change? That's unacceptable.
>At work, how can you just write code without testing the functionality
consider this scenario:
developer is tasked to make an update to a report. He does not have reporting services available locally (long and complicated setup) and neither does he have access to the data he will be reporting on (because of data privacy regulations). He makes the change to the report, checks in the code without any testing and it then blows up in qa. This is a common scenario that i have seen many times before, especially when developing for systems or with data that developers don't have full access to.
There are only two kinds of scenarios that I've seen people do this where it might be vaguely acceptable:
1. Where it is impossible for the developer to test the change himself. For instance, if the bug is not reproducible by the developer due to some difference between the production and development environment that he lacks concrete information about (e.g. external customer). In which case, the developer should test that it didn't break his own system in some additional way and should at least warn the customer that there's no guarantee it'll work.
2. If you are under some contractual obligation to ship on a particular date, and the thing you are shipping is going to be a giant bug ridden turd anyway due to time constraints caused by poor project management. This is not ideal at all, and not something to take any pride in doing, but it may be passably acceptable to cut corners like this if management tells you to because otherwise your employer is going to lose money for not delivering. Especially if you have a "defect release" planned in the contracted schedule later on anyway (e.g. because all parties to the contract already know the schedule is going to produce a turd and planned accordingly).
I've made live changes in production systems without testing them. If the production system is down, it's probably not going to get more down. Some of those changes are made on the live system and then back-ported into the release process. (Sometimes we aren't even sure which supporting index would help enough to come back, or which query to "neuter" to get site functionality mostly back. In cases like that, you might need to do development in production.) I've approved someone else shipping binaries built on a developer desktop to get a production site back functioning more quickly and then commit the changes are re-release from the build/deployment pipeline. We've pushed changes to prod without QA review. There are times to follow the measured, careful, prudent approach to development (most times) and there are other times where a meter of $10K/minute suggests that a lower latency change process is more appropriate and higher EV for the company.
That said, I've seen far more instances of no-reasonable-excuse events where code that was checked into master couldn't possibly compile, people doing an "svn resolve; svn commit" without actually resolving anything and checking in the ====== ++++++ conflict markers and both conflicted sections, etc.
I'm with you - QA should be a double check, a fall-back; if you haven't checked, how is that going to be possible? The risk with coders leaning on QA is that they've outsourced their conscience; and the only people really testing and checking the code don't know it very well. Not good.
FWIW, I think dropping QA for periods to shock those who are starting to lean on it is a good idea; but it should still be there most of the time.
I struggle with this sometimes. There's a line to walk between getting stuff done efficiently. If you stray too far either side of that line, you're going to drag everyone else down.
I have "slowed down" a fair bit, especially at the start of projects where i don't "do" a lot except think through scenarios. I write a lot better code than I used to.
I'm in the same position currently. I'm not available on weekends or extra hours during normal working days, some people are working extra hard and bringing up how much re-factoring needs to be done on their code. Except the extra hours are from fixing their broken mess, and the re-factoring is largely from self-inflicted injuries. Not that there aren't things that I wouldn't re-factor from my own code, but it's considerably less and I do it incrementally when I re-visit those sections instead of pounding my chest about how much work it all was. But the latter is praised.
Ha! Resonates. Used to have a group of comm protocol engineers at our company, the most famous and popular with sales and customers. Reason: their code broke all the time, and they flew places to hack it until it worked. Looked like heroes most of the time. Meanwhile, our group got an award for least-bugs-in-a-release-ever. Well, recognized anyway, no money or promotion or even a plaque. So it goes.
Yeah, exactly. If your stuff "just works" there's a danger that the manager will assume that what you're doing is easy. I, though, regard people who's stuff "just works" as solid gold.
Common problem is these people (who just do their job and make no trouble) are often seen as useless - you don't hear much about them anyway, what are they getting money for at all?? And the fact that their stuff just works makes many people think that they were just lucky to work on much simpler stuff than others - and you know, when code is done and works, especially a high quality code - it looks very simple, a buggy spaghetti code looks a lot more complicated and someone writing it usually has an easy time explaining a non-technical manager that he is working on very complex stuff...
> ...someone writing it usually has an easy time explaining a non-technical manager that he is working on very complex stuff...
This drives me right up the wall. I've also found that these people are masters of stringing together jargon, so even when you sit them down to try and pass on experience it becomes too mentally exhausting trying to parse the Markov chains that fall out of their mouths.
"It seems this call here was inherently looped, boosting the complexity to at least theta x to the logx due to some improperly keyed database API tables. This poses a serious security risk."
"Okay... great... but if you could stop embedding style elements into your pages anyway, I'd really appreciate it."
I would say the first step to competency in recruiting and managing developers is if you can tell when a developer is doing a terrible job. That's more important and easier, and more prone to objective measures. Someone who commits 100 lines a week may be better than someone who commits 200 lines, but the one who hasn't committed in a month may need some help getting things together.
With hiring as difficult as it is, developers who make any reasonable positive contribution are probably worth keeping.
From there, as a manager, the best thing to do is focus on getting the best out of each developer, and keeping the business profitable enough to be able to give raises that would make anyone happy.
> but the one who hasn't committed in a month may need some help getting things together.
They might, but on the other hand they might be the one who decided that the project needed documenting properly, or who is researching and designing the next feature.
This is a good reminder that performance on any metric needs to be tied to decent communication. A problem like this can easily be fixed with "hey, what're you working on?" "oh, this ream of important documentation", but far too often that never happens.
Untested idea: Do regular user surveys asking, "how reliable is the product?" This would provide a measure of how buggy the software is that can be tracked over time.
One quality of good developers not often brought up is empathy. It's absent from this article and all of the comments thus far.
Empathy is quite important in a vast array of creative endeavors. Development is not an exception in my opinion. It's the trait that allows developers to know what a person needs even if it isn't what they're asking for.
Being able to put yourself into the shoes of another busy person working in a domain you may have little familiarity with is difficult. Trying to solve technical problems for that person when they are not technical is harder. Efficiently using that person's time and getting to the root of what the actual problem is, not necessarily what they ask you to do, is harder still.
Getting to the point where you know how to ask the minimal amount of questions to understand the actual problem that needs solving takes practice and experience. It requires good listening and comprehension skills, and comes from caring enough in a person's problems to get to the root of the issue; an exercise in empathy.
By getting to the root of the problem you end up with better, more useful software and solutions, with less iterations. Even having the conversations to achieve these understandings requires knowing your tools well enough to gauge what's possible, an innate curiosity to care enough to dive into whatever it is that needs solving, and enough experience to know when to say "yes," "yes, but," "no," or "I don't know," to ideas. And to not only say it, but mean it, and know it to be true.
Additionally, developers who are good at actually solving problems for people must be creative enough to improve upon that situation without being told how.
All of these traits are excellent separately, but combined produce developers who solve problems and create value, not developers that just write code.
Empathy is a trait of some of the best developers I've ever met or worked with and a lack of empathy has been a strong indicator of mediocre, bad, or hard to work with developers.
Empathy is the just the newest word for certain people to feel that they're better than everyone else (who lacks empathy?).
After a while it gets tiring keeping up with it all, I sometimes think I should try and identify the newest word to add to the word bingo software developers seem to feel the need to employ to differentiate themselves from everyone else.
This is a remarkably dismissive comment. Empathy is not just a new buzz word, it matters a great deal. Some of the best advice i have ever received as a developer was to "think like the client". That is a difficult thing to do, and i do not view it as a reason i am better, i view it as something i am constantly subpar at.
But thinking like your customer is, by definition, empathetic. Intimately understanding a customers needs and reactions to your software will not help you to write academically superior code, but it will help you create better products.
You would think someone who was good at this newfangled "empathy" stuff would've managed to start off their comment in a more positive way.
It's all necessary for writing software, but when someone starts telling me one specific aspect of it is more important than the others, then yes, I absolutely dismiss them. It's code for "I can't write good code, but it's alright because I'm a people person and that makes me more important than the ones who CAN write code".
It's just more egotistical bullshit that's more about the person making the statement than anything else.
Actually no, I have really difficult time with social skills, and I know a lot of other programmer types that struggle in the same areas I do. Where did I imply that I'm better than anyone else?
This is a great point, I think a good developer
-- has respect for other's code and perspective, he/she doesn't think that the previous developer did a bad job writing the code in first place. Many times the the code/solution that is better at times may not be good enough in long run
-- also a good developer is one who would write code/logic in such a way that the future developers would understand it easily. Sometimes having good comments in code could easily increase longevity of the program
Managing a team as a tech lead (that is, I also develop a lot).
I primarily use two techniques; simple project management and communication.
Our developers are not forced to work on the project nor are they assigned by anyone else; they are in the team because they want to work on it (and they can leave at any time). The project management is simple; we have a backlog and engineers are (mainly) free to choose what to work on. We have priority indicators and developers tend to work on things they are already familiar with, but in general one can choose what sounds interesting.
How do we (we are two tech leads) determine if engineers are doing a good job? On the code level, we are doing reviews (everyone can review everyone else's code) and give feedback. We are talking a lot with each other, asking about progress, blockers and new ideas. We also talk about technology in general. We encourage our engineers to look at other things and try new ideas.
And the whole project management is transparent; we as tech leads do most of the communication with the business so that developers can focus on their stuff but we report everything in great detail to them.
We do not use metrics like bug counts. Everyone writes code with bugs. What I recognize is whether engineers can take responsibility for their stuff or not. We "teach" them that mistakes are nothing bad; they are encouraged to say "Hey, that's my fault, I will fix it".
I think we, couldn't use this approach with 20 or 30 developers, but in a small team it as really working for us. And as I see it, our developers have a great time and work and a developer-friendly environment.
I like this. So if the question was "how do you tell which sled dogs are really pulling", your answer would be: you can't, if you're standing on the sled. But if you're one of the dogs, it's a lot easier to tell.
Do we really need to know, in non-subjective way? In a 1000-person company, how many persons have their performance calculated in a non-subjective and vaguely accurate way?
It must surely only be in sales - where sales volume is a great measure, and I think sales people accept that they are allowed and expected to learn the cut-throat techniques to gameify the situation and win.
If we want to force the corresponding personality traits that make such measurement reasonable onto developers - then OK I think story points achieved (aka velocity) is an equivalent measure we can take.
An experienced twisted senior dev would know how to maximise their score there, and make a junior dev look atrocious in comparison, but if its OK for sales then its OK for devs?
(my actual opinion - being subjective and relying on the opinion of good managers is fine. The developer personality matches this.)
A major reason we cannot define what makes a programmer "good" is that we have thus far been unable to define the practice of creating software as a proper engineering discipline [1]. It is difficult to even enumerate the necessary expertise of a "good programmer" in a general way that transfers everywhere- it is a combination of computer science principles, knowledge of specific tools / languages / frameworks, programming idioms, domain knowledge, certain communication and interpersonal skills, etc. Further complicating things, certain types expertise is useful in some problem domains, and useless in others (i.e. COBOL programmers or kernel hackers will have to gain a different sort of expertise to become effective web developers).
This means that one type of programmer can be "good" at rapidly gaining new forms of expertise. Another may be crazy good at a problem domain he/she's been hacking at for years, and have irreplaceable knowledge. Yet another maybe can do both well, but be stuck at a cushy job for 30 years and never realize their full potential at jumping around and building other great things (like some of my old coworkers).
This lack of clarity in the definition of a "job well done" for software teams is a huge source of pain and lost productivity in companies, especially when the stakeholders and the developers themselves are unable to interpret the signals of failure from their teams. There's no real silver bullet [2] to immediately improve the situation, but there is certainly lots of data that can inform one about a dire situation in a team before it's too late to fix it.
- Code itself has lots of empirical data [3] that can predict team performance in projects with enough of a track record.
- Analysis of team composition and practices [4] can uncover deficiencies and lack of confidence in a team, pointing at other underlying project risks.
Currently (as the article described), all of this information is synthesized and estimated in an ad hoc manner by managers and stakeholders. What really needs to happen is for this data to be routinely collected and delivered to managers, stakeholders, and team members.
Here at Mindsight (http://www.mindsight.io), we are trying to tackle such issues. We're building technology that collects all this data and empowers a manager and his/her team to synthesize reports to stakeholders as frequently as their CI system publishes builds.
We may still have a ways to go in evaluating programmers in the general sense. However, there is still much that can be done to help individual teams understand their true progress in a project. Keep an eye on a future Show HN from us!
Great post. It seems a lot of difficulty from judging quality of work is we have no metric to define what quality software is in the first place. People talk of this code code is 'elegant', or it is readable/efficient, but these are just opinions of other developers, and not easily measured.
The Deming solution - re auto workers - was to constantly rotate all workers through different teams, then statistically judge (after accumulating years of repair records for individual cars) which individuals consistently dragged their teams down. You need a lot of data for this to work, obviously; but it does work.
The answer is simple: the manager should be a good developer, and so the manager has the tool to appraise the quality of code, otherwise it will be a bad manager.
This is a little circular though. If you are not able to identify good developers and your criteria for promotion is development ability then you stand a solid chance of promoting someone who just looks like a good developer to the position where they're judging other developers. That can be disastrous.
The problem seldom lies upon the implementation, but within the people and communication.
Programming is not a solo task (unless you do something alone, for yourself, without anyone ever using it). It's all about communicating your deadlines, issues, successes, problems, estimations, risks and decisions to the team/client.
Programming itself is a form of communication. You're usually writing the code for the next developer that's going to have to read it (which might be you in a few months).
As a manager/client if you're not sure if you have a good or a bad programmer, you certainly don't have a good programmer. If you have a programmer that always keeps you up to date and makes sure you understand what's going on, you do have a great programmer in your hands.
Programmers are like art: you can't exactly pinpoint why a particular painting is good but you can usually still put different paintings in rough order of how good they are. It's never that one brush stroke that reveals the quality but the complete picture.
With programmers, there are indirect, subtle signs which may or may not give clues. Sometimes they only validate some good or bad aspects of the programmer.
I think that to really know the only way is to work with the programmer and see what works and what doesn't. Generally the team does have a good notion of who are good and who are just great, although a manager might want to use the information from that source with some grain of salt.
However, it's easier to pinpoint programmers which aren't good, or not completely good. The guy who doesn't get things done. The guy who breaks more stuff than he fixes. The guy who rewrites everyone else's code as the first step in any project or the guy who's always asking help from others for simple things. Or the guy who is actually a good programmer but always ends up doing something a bit different than what the important things to do are. Or the good programmer who is relentless in insisting he's right because "that's what the facts are" while completely ignoring social issues such as understanding that a dictatorian attitude doesn't fly well with other programmers. These guys still do provide some value but you can see these shortcomings from far away. Then there are the guys who actually produce negative values, i.e. taking away others' time merely by being employed.
> "developers can be confident that they will rewarded for doing the right thing, not looking like they are doing the right thing"
From my professional experience (10 years in 3 companies), this is one of the biggest issues in software development businesses. You're either too small and then the manager doesn't have the time or skill set to effectively evaluate the developer's efficiency or you're too big and there are too many layers between the developer and the manager. The situation when your direct supervisor is also a person who is authorized (and able!) to evaluate your performance happens so rarely.
220 comments
[ 2.9 ms ] story [ 292 ms ] threadThis is the most important but also impossible for non-technical managers, or even technical ones that were never that good themselves.
Are there companies out there the do independent audits of developers/code quality? If always wondered if there is a business opportunity there.
To audit the code accurately (as opposed to merely giving out aesthetic advice), in most cases would involve learning the domain, and this is what's expensive.
To the business folks, we're a black box. Stuff goes in, stuff comes out. And it costs. Paying someone else at least as much to prove that we did it according to 'best practice' (I think this is what you're suggesting?) would be anathema.
There might be a business there but it's not mass market.
It's probably also worth noting that all of the above applies to other domains too. Substitute 'code' for 'marketing' quality. In some real senses, die welt ist alles was der fall ist.
There are a lot of things between aesthetics and domain knowledge that are audit-able. A lot of code bases you can walk into and see a million n+1 queries right away and the architectural patterns that lead to them. Another canary is the test complexity that reveals various anti-patterns like active record. Another is correct IOC usage, a lot of code bases will use it for creating POCO objects for example. These are all very common and quickly discoverable.
> So, this sort of devolves to economics, at least where I work. What I mean is, the people that pay for the code don't care and don't care to know. And this is entirely rational from their point of view. If it appears to work, it's good.
I wonder if you could go in and say "this project is costing you $10 million" and we can give you an early indication of whether it's going to be worthwhile or be a turd.
"If dogs could talk, perhaps we would find it as hard to get along with them as we do with people."
The final group does care, often because there arse is on the line and are often a CXO. These are the ones that love Agile/scrum because they think it'll identify problems early and/or they don't trust their Devs.
Whether a solid business case could be sold I'm not sure, but I think everyone that ever hired a scrum consultant would be the target market.
Whether or not a developer is "good", and "how good", is purely subjective.
This is the core problem at the heart of all recruiting, and no matter how hard people try to quantify, test, assess and interview, it is still not possible to make an objective statement about how "good" a developer is.
Part of the issue is that "good" depends on a vast array of factors: the task at hand, the developers experience with the specific technologies, how they feel today, who the judge is, if the developer is feeling good or bad today, if the developer is interested in this specific task etc etc etc etc it goes on and on.
And one of the worst traps to fall into is to think that a developers "ability to code" in some way is a really good measure of how good that developer is. i.e. how quickly can you reverse an array, sort of dict of arrays etc. To my mind this is only a certain portion of what goes to make a great developer, and not even necessarily a very large or important portion. So many other things are important in making "a good developer" that assessing substantially on code seems misguided.
Most importantly, "good" to me, is definitely not the same as "good" to you, because the important things for you are likely completely different to the important things to me.
I wrote a post about some of the characteristics of a great software developer, but even this does little to nothing in terms of providing a "science" for the evaluation of how good a programmer is.
http://www.supercoders.com.au/blog/50characteristicsofagreat...
The best description for a good programmer that I have ever heard is from Joel Spolsky who suggested to employ people who are "smart and get stuff done". Interestingly, almost no employers take this approach to recruiting.
You point out there numerous different dimensions of good coding. Consider an IQ test, it has many different categories, but since these strengths are correlated, you can compute an overall "score" for something very abstract like intelligence.
Why should we not, if we dedicate effort, be able to make something similar for coding? Aptitudes are already measured very effectively in many other disciplines (LSATs, MCATS, Putnams, SAT II)
This reminds me of the famous "what the British mean" :
-What the developer says : "This is very interesting"
-What the developer thinks : "That is clear nonsense"
-What the manager understands : "They are impressed"
I sympathize with your plight, but if you can't do the job, you can't keep cashing the checks.
The best answer is, wait a couple decades. Of course, that's not the answer you want, you want to know now. Close code reviews (plural) may tell. Ratios of kinds of bugs may also be a tell (if they're committing more dumb syntactic mistakes that debuggers easily catch they're probably good, and spending their time preventing ugly and subtle logic errors.)
But to the extent that algorithm choice and design is part of their job, that may not be enough.
Yeah, no kidding. Welcome to white collar work.
My experience tells me that the best developers are: - generous with their time to other devs
- not defensive about their code
- able to solve complex problems fast, and explain those solutions to other people
- able to focus really intensely
- enthusiastic about learning new things
- lazy about boring stuff (to the extent that they will spend 4 hours looking for a shortcut that saves them doing 1 hour of boring stuff)
but some of the most productive programmers I've worked with treated the entire thing as a job that they did from 9 to 5 to pay the bills, and their real interest lay elsewhere
and some of the best programmers I've seen were the hardest to manage, and ultimately were a net negative to the team
Coding is creative - there are an infinite number of ways to solve any given problem. This is why it's so hard to predict and manage, and resists quantification.
<edit for formatting>
The "best" programmers you mentioned, from my experience, always end up souring the whole team. Most of the time, they can't seem to tell the forest from the trees.
With that in mind, one of the things I tell my team we always need to hire more of are just developers with social skills. Being effective at working with a team is 100x more important than being a good developer. As an example, I have spent weeks in meetings debating archetecture. Each meeting I would make my same suggestions and then the rest of our "best" developers would debate. By the 6th or so meeting regarding the architecture I just presented a prototype of the project. I won the debate by acting, not by trying to find an ideal solution.
Both types can do good or bad for you.
Edit: iow, smart and get things done, not or.
Having such a constant in your mind would be indicative of never having to do something 'hard' (algorithmic, latency related, extract every single bit of performance b/c you have to)
A bad developer subtracts business value.
Ultimately, in a business setting, those are the only two metrics that matter.
Selection is a management problem, and like many management problems the median level of understanding is primitive and often dysfunctional.
Not many businesses understand how many flavours developers are available in, nor how to match those flavours to the team/project roles they need at that time. So they robo-hire with standard CS whiteboard hazing, or interview for "cultural fit", or some other nonsense.
The hard-headed hiring question is always "Will this person make the business more money, and if so, how?"
This may sound like a recipe for a sweat shop, but it really isn't. There's a lot of possible variation in "how", which includes making smart architectural choices, having good team lead skills, raising the company profile through social presence, and so on.
The strongest possible code is always a good thing, but sometimes it's fine if it's eclipsed by other qualities. You're hiring a person with many possible skills, not a cog in a machine that you're planning to spin as fast as possible until it breaks.
It's up to management to work out how to get value from that. And there's a lot of creative potential in management that traditional work cultures overlook.
What makes a good insurance policy?
"Will buying this insurance make the business more money, and if so, how?" is a little more nuanced, since it requires consideration of risk, and dependent, unknown factors.
I evaluate my team on their ability to ship regularly and with a consistently low bug count. I encourage communication regularly and pair programming and all that. And I am around and I listen and interact.
It is pretty easy to tell when someone isn't pulling their weight or is having problems contributing based on the interactions within the team. People naturally express frustration (as well as praise)... you just have to be an active, hands on (not micromanaging necessarily) manager.
In addition, I specifically look for growth mentality when hiring and cultivate it within the team. That way I can be confident that when a weakness or need for improvement is identified, the person will work on it. It's my job as manager to properly address it and motivate the person.
In my experience, KPIs and other measurables (including even basic timesheets) are always gamed by developers. And anyway there are so many intangible and abstract aspects to doing this job, especially as you advance in your career, that it's arguable that the most important parts of the work aren't even measurable in any real sense in the first place. That's the art.
In academia, articles that are referenced more frequently are "more important". For page ranking, pages that are referenced more frequently, are more important. I wonder if there's an equivalent with infrastructure programming? If a developer builds a subsystem that is used frequently, does that indicate the developer has provided substantive value?
Not really. Story points are cost estimates--a subjective judgement of how much effort a story will take. They're a prediction tool, not a productivity measure. It's very easy to increase the # of story points you deliver just by increasing your estimate and possibly even sandbagging. Not good.
If story points were value estimates, created by a business folks rather than developers, they'd be better measures. But even then they'd be subject to gaming. It's easy to increase velocity in the short term by incurring technical debt. Say, not writing enough (or good enough) tests. Or not helping out co-workers. Or not spending time understanding business context. Or...
It's something to add to the toolbox, and a consistently low score for one person is a sure sign of trouble, but ithe does have some of the same shortcomings the other approaches do.
The amount of points to award is the tricky point, maybe it depends on company culture. How much value does the lovable team player bring, how much value does the awkward quietly-fix-anything person bring?
It doesn't work at all when the team members are not so strong. They tend to value people who don't question "best practices" and don't take bold, unconventional positions. In essence, groupthink wins.
Then, how technically challenging can the task get while the developer maintains the same level of productivity?
–Technical (ability to effectively solve problems)
–Business (picking which problems to solve)
–Productivity (things done to improve workflows, automate processes, etc. of themselves & team)
–Team (teaching, hiring, training)
This works pretty well. I find that these skills are multiplicative, so someone's impact on the team is reasonably well-approximated by taking an average of these scores. I also find many things you might expect, e.g. variance in technical skill is pretty high, talented engineers usually develop high technical skills before high skills in the other domains, senior engineers tend to be force multipliers by being exceptional at the non-technical skills, etc.
The challenge here is that a human is evaluating all of these traits (you). Of course you think you're not biased, but research shows all humans are [e.f. more likely to promote people who remind them of themselves, without being threatening].
I think much like if an engineer made code and said "it's working great" without any kind of external monitoring to validate, asking a manager to promote without external validation is completely a crap-shoot.
[0] See: "Making Learning Whole" by David Perkins
I'd say a developer is doing a good job when you, as a manager, are not having him come in at all hours to fix problems with his stuff.
Other signs of a good developer are you don't have to micromanage him, and he's more of a partner helping you get things done rather than a subordinate you've got to spell things out for and check up on.
I.e. when he's on the job and you can relax and concentrate on other things, you've got a good 'un.
https://www.joelonsoftware.com/2006/10/25/the-guerrilla-guid...
http://steve-yegge.blogspot.de/2008/06/done-and-gets-things-...
An engineer can get things done quickly but that doesn't mean it's done correctly and won't break (and someone else will have to fix it).
To complicate things more, a feature might seem to work perfectly, until a certain point when you realize that it's all wrong at an architectural level and you have to rewrite everything.
If something doesn't work then it's not done.
To complicate things more, a feature might seem to work perfectly, until a certain point when you realize that it's all wrong at an architectural level and you have to rewrite everything.
If the requirements have changed then a new piece of work is needed. That doesn't invalidate the previous work; it just means things have changed.
Thus future proofing isn't just a waste of time, it's actively counter productive. The predicted requirements are rarely correct although the extra code remains a liability.
Right. And this applies to other disciplines too. "Heavy retrospective refactoring" is exactly what a writer does each time they go back and make edits to a piece. Connections between elements such as characters, themes, writing style, and dialogue are felt out only by emitting draft after draft.
Even this comment went through many edits to get into this shape. These two sentences alone have been rewritten ten times.
In my experience there's also value in imposing a framework once one has done enough emitting of raw material. For code this might be looking for ways to extract common logic out of several similar functions. For writing this might be considering how two characters have "interacted" so far and what other details ought to fill out their relationship (without considering whether or not all those details will manifest overtly in the work.)
lol. Really dude?
http://wiki.c2.com/?YouArentGonnaNeedIt
It wouldn't be smart to build something that is un-maintainable or prone to breaking in the future if that's what was needed, would it?
At some point, you have to go with what you know. You can't expect perfect knowledge on the part of those in the past.
That's also what a developer who ships nothing, ever, looks like. There are quite a few of those. A developer who gets the most done and tackles the hardest work, on the most important and frequently used tools, integrating with the most problematic 3rd party systems and has specialist knowledge is likely to be called on a lot.
Ultimately you can't make any judgement of the developer without detailed understanding of the specifics of the work. This applies to every possible developer productivity metric which is why its so damned hard.
You've nailed it. This is why I would go so far as to say that someone with no programming experience can't effectively manage developers.
How are the other two points mentioned earlier related to remote working? I am curious.
From what I've seen coding managers seem much more open to remote work than non-coding managers.
So, while it's rare there are certainly managers out there who can.
This reminds me strongly on yesterday's Dilbert: http://dilbert.com/strip/2017-02-09
They rely a lot more on their technical leads to tell them how the other devs are doing at a technical level. They're perfectly capable of managing their professional development without having an in-depth knowledge of enterprise architecture or C#.
So the leads are de facto managers in that they're assisting the manager in managing the other developers. I think this can work, but I don't think it contradicts what I said. It just means the leads wind up doing some managing even though that's not what their titles say.
Was he a good developer? Looking at his github repo I would have said yes... talking to him I said yes... if I had examined what he built without any context I would have said yes, but really he was something of a company destroyer that I would not ever recommend to anyone else.
Conceptual damage to an application is a lot harder to fix than the damage of 'ugly' code. You spend years fully recovering from fundamental flaws in the concepts of your application.
My thinking is, QA isn't there to find my bugs. They're there to make sure I don't have any. I seem to be in the minority on that thinking.
Even today it would never occur to me to make a change and push without testing said change, although I see people do it all the time.
How is this even a thing? I don't understand it, yet I come across it time after time.
If you weren't self-educated, did you just throw together assignments without testing them? At work, how can you just write code without testing the functionality.
I've seen people work on webapps that didn't bother to navigate to page they changed. I'd pull in code, go to test my change, and find that the page looks like a GeoCities atrocity. Then I start rolling back changes only to find the code I pulled is the culprit.
I can understand writing a unit test that doesn't cover as well as one thinks. Not taking 15 seconds to visually inspect a visual change? That's unacceptable.
consider this scenario: developer is tasked to make an update to a report. He does not have reporting services available locally (long and complicated setup) and neither does he have access to the data he will be reporting on (because of data privacy regulations). He makes the change to the report, checks in the code without any testing and it then blows up in qa. This is a common scenario that i have seen many times before, especially when developing for systems or with data that developers don't have full access to.
1. Where it is impossible for the developer to test the change himself. For instance, if the bug is not reproducible by the developer due to some difference between the production and development environment that he lacks concrete information about (e.g. external customer). In which case, the developer should test that it didn't break his own system in some additional way and should at least warn the customer that there's no guarantee it'll work.
2. If you are under some contractual obligation to ship on a particular date, and the thing you are shipping is going to be a giant bug ridden turd anyway due to time constraints caused by poor project management. This is not ideal at all, and not something to take any pride in doing, but it may be passably acceptable to cut corners like this if management tells you to because otherwise your employer is going to lose money for not delivering. Especially if you have a "defect release" planned in the contracted schedule later on anyway (e.g. because all parties to the contract already know the schedule is going to produce a turd and planned accordingly).
I've made live changes in production systems without testing them. If the production system is down, it's probably not going to get more down. Some of those changes are made on the live system and then back-ported into the release process. (Sometimes we aren't even sure which supporting index would help enough to come back, or which query to "neuter" to get site functionality mostly back. In cases like that, you might need to do development in production.) I've approved someone else shipping binaries built on a developer desktop to get a production site back functioning more quickly and then commit the changes are re-release from the build/deployment pipeline. We've pushed changes to prod without QA review. There are times to follow the measured, careful, prudent approach to development (most times) and there are other times where a meter of $10K/minute suggests that a lower latency change process is more appropriate and higher EV for the company.
That said, I've seen far more instances of no-reasonable-excuse events where code that was checked into master couldn't possibly compile, people doing an "svn resolve; svn commit" without actually resolving anything and checking in the ====== ++++++ conflict markers and both conflicted sections, etc.
"There, I fixed it!"
FWIW, I think dropping QA for periods to shock those who are starting to lean on it is a good idea; but it should still be there most of the time.
Is it stuff that he wrote or work he inherited?
This drives me right up the wall. I've also found that these people are masters of stringing together jargon, so even when you sit them down to try and pass on experience it becomes too mentally exhausting trying to parse the Markov chains that fall out of their mouths.
"It seems this call here was inherently looped, boosting the complexity to at least theta x to the logx due to some improperly keyed database API tables. This poses a serious security risk."
"Okay... great... but if you could stop embedding style elements into your pages anyway, I'd really appreciate it."
Someone who did half as much work and made half as many mistakes was a much better employee as far as he was concerned.
With hiring as difficult as it is, developers who make any reasonable positive contribution are probably worth keeping.
From there, as a manager, the best thing to do is focus on getting the best out of each developer, and keeping the business profitable enough to be able to give raises that would make anyone happy.
They might, but on the other hand they might be the one who decided that the project needed documenting properly, or who is researching and designing the next feature.
Not all useful work involves writing code.
Empathy is quite important in a vast array of creative endeavors. Development is not an exception in my opinion. It's the trait that allows developers to know what a person needs even if it isn't what they're asking for.
Being able to put yourself into the shoes of another busy person working in a domain you may have little familiarity with is difficult. Trying to solve technical problems for that person when they are not technical is harder. Efficiently using that person's time and getting to the root of what the actual problem is, not necessarily what they ask you to do, is harder still.
Getting to the point where you know how to ask the minimal amount of questions to understand the actual problem that needs solving takes practice and experience. It requires good listening and comprehension skills, and comes from caring enough in a person's problems to get to the root of the issue; an exercise in empathy.
By getting to the root of the problem you end up with better, more useful software and solutions, with less iterations. Even having the conversations to achieve these understandings requires knowing your tools well enough to gauge what's possible, an innate curiosity to care enough to dive into whatever it is that needs solving, and enough experience to know when to say "yes," "yes, but," "no," or "I don't know," to ideas. And to not only say it, but mean it, and know it to be true.
Additionally, developers who are good at actually solving problems for people must be creative enough to improve upon that situation without being told how.
All of these traits are excellent separately, but combined produce developers who solve problems and create value, not developers that just write code.
Empathy is a trait of some of the best developers I've ever met or worked with and a lack of empathy has been a strong indicator of mediocre, bad, or hard to work with developers.
I've thought this for awhile, it's encouraging to see someone else draw the same conclusion.
After a while it gets tiring keeping up with it all, I sometimes think I should try and identify the newest word to add to the word bingo software developers seem to feel the need to employ to differentiate themselves from everyone else.
But thinking like your customer is, by definition, empathetic. Intimately understanding a customers needs and reactions to your software will not help you to write academically superior code, but it will help you create better products.
It's all necessary for writing software, but when someone starts telling me one specific aspect of it is more important than the others, then yes, I absolutely dismiss them. It's code for "I can't write good code, but it's alright because I'm a people person and that makes me more important than the ones who CAN write code".
It's just more egotistical bullshit that's more about the person making the statement than anything else.
I primarily use two techniques; simple project management and communication.
Our developers are not forced to work on the project nor are they assigned by anyone else; they are in the team because they want to work on it (and they can leave at any time). The project management is simple; we have a backlog and engineers are (mainly) free to choose what to work on. We have priority indicators and developers tend to work on things they are already familiar with, but in general one can choose what sounds interesting.
How do we (we are two tech leads) determine if engineers are doing a good job? On the code level, we are doing reviews (everyone can review everyone else's code) and give feedback. We are talking a lot with each other, asking about progress, blockers and new ideas. We also talk about technology in general. We encourage our engineers to look at other things and try new ideas.
And the whole project management is transparent; we as tech leads do most of the communication with the business so that developers can focus on their stuff but we report everything in great detail to them.
We do not use metrics like bug counts. Everyone writes code with bugs. What I recognize is whether engineers can take responsibility for their stuff or not. We "teach" them that mistakes are nothing bad; they are encouraged to say "Hey, that's my fault, I will fix it".
I think we, couldn't use this approach with 20 or 30 developers, but in a small team it as really working for us. And as I see it, our developers have a great time and work and a developer-friendly environment.
It must surely only be in sales - where sales volume is a great measure, and I think sales people accept that they are allowed and expected to learn the cut-throat techniques to gameify the situation and win. If we want to force the corresponding personality traits that make such measurement reasonable onto developers - then OK I think story points achieved (aka velocity) is an equivalent measure we can take.
An experienced twisted senior dev would know how to maximise their score there, and make a junior dev look atrocious in comparison, but if its OK for sales then its OK for devs?
(my actual opinion - being subjective and relying on the opinion of good managers is fine. The developer personality matches this.)
This means that one type of programmer can be "good" at rapidly gaining new forms of expertise. Another may be crazy good at a problem domain he/she's been hacking at for years, and have irreplaceable knowledge. Yet another maybe can do both well, but be stuck at a cushy job for 30 years and never realize their full potential at jumping around and building other great things (like some of my old coworkers).
This lack of clarity in the definition of a "job well done" for software teams is a huge source of pain and lost productivity in companies, especially when the stakeholders and the developers themselves are unable to interpret the signals of failure from their teams. There's no real silver bullet [2] to immediately improve the situation, but there is certainly lots of data that can inform one about a dire situation in a team before it's too late to fix it.
- Code itself has lots of empirical data [3] that can predict team performance in projects with enough of a track record.
- Analysis of team composition and practices [4] can uncover deficiencies and lack of confidence in a team, pointing at other underlying project risks.
Currently (as the article described), all of this information is synthesized and estimated in an ad hoc manner by managers and stakeholders. What really needs to happen is for this data to be routinely collected and delivered to managers, stakeholders, and team members.
Here at Mindsight (http://www.mindsight.io), we are trying to tackle such issues. We're building technology that collects all this data and empowers a manager and his/her team to synthesize reports to stakeholders as frequently as their CI system publishes builds.
We may still have a ways to go in evaluating programmers in the general sense. However, there is still much that can be done to help individual teams understand their true progress in a project. Keep an eye on a future Show HN from us!
[1] http://repository.cmu.edu/cgi/viewcontent.cgi?article=2967&c... [2] http://worrydream.com/refs/Brooks-NoSilverBullet.pdf [3] https://www.microsoft.com/en-us/research/wp-content/uploads/... [4] https://wweb.uta.edu/management/Dr.Casper/Fall10/BSAD6314/BS...
Programming is not a solo task (unless you do something alone, for yourself, without anyone ever using it). It's all about communicating your deadlines, issues, successes, problems, estimations, risks and decisions to the team/client.
Programming itself is a form of communication. You're usually writing the code for the next developer that's going to have to read it (which might be you in a few months).
As a manager/client if you're not sure if you have a good or a bad programmer, you certainly don't have a good programmer. If you have a programmer that always keeps you up to date and makes sure you understand what's going on, you do have a great programmer in your hands.
With programmers, there are indirect, subtle signs which may or may not give clues. Sometimes they only validate some good or bad aspects of the programmer.
I think that to really know the only way is to work with the programmer and see what works and what doesn't. Generally the team does have a good notion of who are good and who are just great, although a manager might want to use the information from that source with some grain of salt.
However, it's easier to pinpoint programmers which aren't good, or not completely good. The guy who doesn't get things done. The guy who breaks more stuff than he fixes. The guy who rewrites everyone else's code as the first step in any project or the guy who's always asking help from others for simple things. Or the guy who is actually a good programmer but always ends up doing something a bit different than what the important things to do are. Or the good programmer who is relentless in insisting he's right because "that's what the facts are" while completely ignoring social issues such as understanding that a dictatorian attitude doesn't fly well with other programmers. These guys still do provide some value but you can see these shortcomings from far away. Then there are the guys who actually produce negative values, i.e. taking away others' time merely by being employed.
From my professional experience (10 years in 3 companies), this is one of the biggest issues in software development businesses. You're either too small and then the manager doesn't have the time or skill set to effectively evaluate the developer's efficiency or you're too big and there are too many layers between the developer and the manager. The situation when your direct supervisor is also a person who is authorized (and able!) to evaluate your performance happens so rarely.