6 ms·

Here's a profile of a developer: - Easy going and pleasant. - Really interested in programming and tech in general - Talks intelligently about the proble

Here's a profile of a developer: - Easy going and pleasant. - Really interested in programming and tech in general - Talks intelligently about the problem at hand. Asks all the right questions. Agrees a plan of action in collaboration with colleagues. - Creates systems that definitely appear to work - Code looks pretty sane. Structure is right. Style seems good. - Always very responsive to problems. Jumps straight on them. - Every problem fixed another one seems to pop up. - Eventually you dig into the code and problem space in detail and you find that in a very subtle, even complex way the whole thing is completely wrong, the problem space misunderstood and everything patched over with little fixes to get things working for a particular case. In the end no system created by the person is useable without major remediation by another developer. Anyone experienced this?

maltesers 8y ago
Because they're fixing some other problem they want to work on. Not the problem they actually have. They know it.
mahemm 8y ago
Sounds like insufficient testing to me. This kind of deep/far reaching issue should have been crashing tests written before others would have seen it. Assuming that there is some testing in their work (if not; there's the answer), my guess would be that it's largely sanity testing of each functionality in a vaccuum. The coaching would probably be to demonstrate more integration-style testing, possibly using whatever tests caught system-level issues that the dev has pushed in the past.
- kyberias 8y ago
  No, it's just lack of true skill.
- potta_coffee 8y ago
  Could also be organizational. Constantly shifting whims of stakeholders, etc. Yes, requirements change but changing major requirements without a major refactor can cause these kinds of problems with the code. Or if the developer is being given unreasonable deadlines, no time/resources for testing, etc etc.
- EpicEng 8y ago
  >the problem space misunderstood and everything patched over with little fixes to get things working for a particular case. Sounds like testing found issues which were hacked over, but more will keep popping up because the design is inherently incorrect.
kyberias 8y ago
Yes. Very enthusiastic, outspoken, easy going, pleasant to work with, but really can't complete the tasks without someone going back and fixing it.
- gerbilly 8y ago
  > easy going, pleasant to work with This is a survival tactic, and in a way it's a dishonest put on. If the same developer were abrasive arrogant and difficult to get along with, then the other programmers, who always have to fix his work, would have him run out of the company. Meanwhile, sometimes the crustiest curmudgeons in a team are the ones who have the most experience and knowledge to impart if you get to know them.
gerbilly 8y ago
I have definitely experienced this. Imagine a competent developer writes a mostly correct system with few bugs, and that requires few fixes over time. Management will likely perceive the first incompetent developer as better than the more competent one. Why? Because the incompetent developer is seen to be fixing problems all the time, which is a positive thing.[1] (You could say his work is more 'salient' to management.) Frustratingly, the incompetent guy comes off as a rock star. [1] Ignorant of the fact that the problems were created by the developer himself.
- ozim 8y ago
  In big companies maybe, in small company I would say I took over job of guys that were firefighting awesomely. If they would continue doing that, company would go under. When I joined, big customer was already starting to pull out because there were constant issues, though fixed by brilliance of those guys. With me on board and those guys gone there is a lot less issues and guess what... My boss has time to drive around country to bring in new customers and we are growing. When there were issues my boss had to stay around in office to keep track of problems and fight hard to keep customers from leaving. I don't say that your story is not true, but those guys in your management are lamentable, they don't understand how much more could be done if they would not have those problems in first place...
  - gerbilly 8y ago
    > I don't say that your story is not true, but those guys in your management are lamentable, they don't understand how much more could be done if they would not have those problems in first place... In large companies with more layers between developers and the customer, this kind of dynamic can go on for a while. I've seen it many times.
jancsika 8y ago
> - Code looks pretty sane. Structure is right. Style seems good. You're attributing that bullet point to the wrong developer. Here's a profile of a reviewer: - Isn't paying sufficient attention to the code being submitted. Don't get me wrong-- I've ripped away drywall to reveal nastiness before. But what you've described is systemic, and for that the reviewer must share some responsibility.
- scandox 8y ago
  Look I'm happy to take my part of the blame but some of what was wrong was so damn subtle. Ultimately one does trust people to make design decisions at some level of code that one does not second guess...
  - jancsika 8y ago
    But you wrote that none of the systems this developer implemented were even usable without intervention. What's the point of reviewing code if you don't eventually read some of it in enough detail to clamp down? Or at least revisiting the design of your tests.
user5994461 8y ago
Not before 5 or 10 years. Patches and fixes have accumulated in response to strange edge case and bugs you wouldn't believe if told. The organization and the problem space have shifted somewhat over time. A few things could have been done differently in the new environment.
deleted 8y ago
[deleted]

maltesers 8y ago

Because they're fixing some other problem they want to work on. Not the problem they actually have. They know it.

mahemm 8y ago

Sounds like insufficient testing to me. This kind of deep/far reaching issue should have been crashing tests written before others would have seen it. Assuming that there is some testing in their work (if not; there's the answer), my guess would be that it's largely sanity testing of each functionality in a vaccuum. The coaching would probably be to demonstrate more integration-style testing, possibly using whatever tests caught system-level issues that the dev has pushed in the past.

kyberias 8y ago
No, it's just lack of true skill.
potta_coffee 8y ago
Could also be organizational. Constantly shifting whims of stakeholders, etc. Yes, requirements change but changing major requirements without a major refactor can cause these kinds of problems with the code. Or if the developer is being given unreasonable deadlines, no time/resources for testing, etc etc.
EpicEng 8y ago
>the problem space misunderstood and everything patched over with little fixes to get things working for a particular case. Sounds like testing found issues which were hacked over, but more will keep popping up because the design is inherently incorrect.

kyberias 8y ago

Yes. Very enthusiastic, outspoken, easy going, pleasant to work with, but really can't complete the tasks without someone going back and fixing it.

gerbilly 8y ago
> easy going, pleasant to work with This is a survival tactic, and in a way it's a dishonest put on. If the same developer were abrasive arrogant and difficult to get along with, then the other programmers, who always have to fix his work, would have him run out of the company. Meanwhile, sometimes the crustiest curmudgeons in a team are the ones who have the most experience and knowledge to impart if you get to know them.

gerbilly 8y ago

I have definitely experienced this. Imagine a competent developer writes a mostly correct system with few bugs, and that requires few fixes over time. Management will likely perceive the first incompetent developer as better than the more competent one. Why? Because the incompetent developer is seen to be fixing problems all the time, which is a positive thing.[1] (You could say his work is more 'salient' to management.) Frustratingly, the incompetent guy comes off as a rock star. [1] Ignorant of the fact that the problems were created by the developer himself.

ozim 8y ago
In big companies maybe, in small company I would say I took over job of guys that were firefighting awesomely. If they would continue doing that, company would go under. When I joined, big customer was already starting to pull out because there were constant issues, though fixed by brilliance of those guys. With me on board and those guys gone there is a lot less issues and guess what... My boss has time to drive around country to bring in new customers and we are growing. When there were issues my boss had to stay around in office to keep track of problems and fight hard to keep customers from leaving. I don't say that your story is not true, but those guys in your management are lamentable, they don't understand how much more could be done if they would not have those problems in first place...
- gerbilly 8y ago
  > I don't say that your story is not true, but those guys in your management are lamentable, they don't understand how much more could be done if they would not have those problems in first place... In large companies with more layers between developers and the customer, this kind of dynamic can go on for a while. I've seen it many times.

jancsika 8y ago

> - Code looks pretty sane. Structure is right. Style seems good. You're attributing that bullet point to the wrong developer. Here's a profile of a reviewer: - Isn't paying sufficient attention to the code being submitted. Don't get me wrong-- I've ripped away drywall to reveal nastiness before. But what you've described is systemic, and for that the reviewer must share some responsibility.

scandox 8y ago
Look I'm happy to take my part of the blame but some of what was wrong was so damn subtle. Ultimately one does trust people to make design decisions at some level of code that one does not second guess...
- jancsika 8y ago
  But you wrote that none of the systems this developer implemented were even usable without intervention. What's the point of reviewing code if you don't eventually read some of it in enough detail to clamp down? Or at least revisiting the design of your tests.

user5994461 8y ago

Not before 5 or 10 years. Patches and fixes have accumulated in response to strange edge case and bugs you wouldn't believe if told. The organization and the problem space have shifted somewhat over time. A few things could have been done differently in the new environment.

deleted 8y ago

[deleted]