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