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.
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.
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
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.
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.
https://www.joelonsoftware.com/2006/10/25/the-guerrilla-guid...
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.)
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.
http://steve-yegge.blogspot.de/2008/06/done-and-gets-things-...
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.
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.