7 ms·

TBH, I read this as: we mismanaged the project for months (years?), reduced scope creep by negotiating with the client, and finally implemented what should have

TBH, I read this as: we mismanaged the project for months (years?), reduced scope creep by negotiating with the client, and finally implemented what should have been the version 1.0 solution while shifting the blame entirely on the loner dev who worked himself into a corner trying to catch up to our sales department's untenable promises. Everyone created the problem, the dev was an easy target to eat the blame because of his ego. "We could not build a hotel, so we bought new hammers and built a great dog house instead."

pdwetz 9y ago
Also, I'm not sure I'd apply the label "genius" with someone who has copious amounts of "copy pasta" in his solely crafted code base.
- imustbeevil 9y ago
  Makes you wonder why the company would consider him their "top talent".
  - zeveb 9y ago
    I imagine that it's because he delivered, rather than taking the time to abstract away stuff which might not need to be abstracted away. Remember that very, very few organisations (companies or in academia) have 'quality code' as an overarching goal: rather, they want good enough code, soon. Time after time I've seen developers fall into one of two traps: abstracting too soon or too late. It's very, very difficult to avoid. My preferred method is to just hack together something that works over a couple of iterations, then spend an iteration refactoring. It's hard to convince a business that this refactoring time isn't wasted, but it is in fact extremely valuable to the code base. 'I need to do this now so that I can satisfy your change requests later' sometimes works.
mattbgates 9y ago
I think I have to agree with you. The fact that Rick was allowed to be turned from a Dr. Jekyll to a Mr. Hyde is kind of the company's fault. No one stepped in to hold Rick accountable during meetings? While I no longer work there, my first job with some programming had me training to understand the code, what it was about, and even how to write it. To this day, I still use this method so I don't get lost or bored in my code. These are the lines I actually use along with commenting my own code just in case I have to return back to it weeks or months or even years later, I don't have to try and trace every step back to a particular code. // AUTHOR: MG // FILENAME: functions.php // STATUS: ACTIVE // PURPOSE: All of the functions for this application (app name) // NOTES: There are several unused functions in this file that are commented out but once in production // They can be deleted as we likely will not be needing them at all. Those 5 lines have saved me a lot of time. While I don't include the "author" line since it just me writing the code, if there are tons of hands in there, you should know EVERY SINGLE author as well as when code gets commented, it should contain the initials upfront, such as // mg: this does this and this does that. If I know multiple files touch.. I also add: "ASSOCIATIONS:" and list all files that call this one. Using this method, I've been able to complete a bunch of projects much quicker because any time I start to forget: what am I doing? what does this code do? am I on the right track? I can look right at the beginning of a file and know the answer. I'm not saying that a boss or supervisor has to be a micromanager, but meetings are necessary to understand where everyone is at. Leaving a programmer to do his own thing means that he really is doing his own thing and is more likely to get lost in the code. I'd say more like he wasn't a genius but thought he could do it alone.. and sometimes, it is nice to have someone step in and tell you: "Hey where we at? What can we do to speed this up?" or even provide their own insight... I can't tell you how many times I've talked with my spouse about an issue.. and she's suggested, "Why don't you just do this?" and it has saved me hours of time just because of someone not in the code is able to see another solution.
- Avalaxy 9y ago
  > AUTHOR: MG This is already in your commit history, so why hardcode it into the source? > FILENAME: functions.php This is obvious because you just opened the file. So again, why even put it there? When the file gets renamed the documentation is no longer correct? These things are also hard to refactor. > STATUS: ACTIVE Every part of the code is always active... > PURPOSE: All of the functions for this application (app name) Okay, probably the most useful one here. But what if we're refactoring the code and the purpose changes? Or if someone adds a few functions and the documentation no longer covers the purpose? > NOTES: There are several unused functions in this file that are commented out but once in production They can be deleted as we likely will not be needing them at all. Very dangerous, again because the source might change while the documentation doesn't. But why even write "they can be deleted"? Why not just delete them? That's what version control is for.
  - nowbacktowork 9y ago
    I'm not sure why you're being down voted, but this is a very reasonable counter point. The purpose or brief should be at the top of every file, it should also evolve as class or implementation does. Arguable that it's really the only one that matters and can also come from no other tool or location.
  - mattbgates 9y ago
    Avalaxy, while I know companies use tools to do their thing... I don't, I'm old school. I have files on an FTP server and I write PHP code. But to explain: > Author: completely optional, depends on what you are using, you aren't wrong.. since I'm old fashioned, if I were to hire some coder to help me maintain my programs, I'd like to know that he was in there, and I'd have no way of knowing.. again, probably not anyone's issue, but I'm old fashion. > Status: Not all files are in use, but sometimes they are just leftover and may not be deleted, or sometimes, they might be used for testing purposes -- so Status can be changed to INACTIVE, TESTING PURPOSES ONLY, etc. Maybe the file is inactive because newer code was written, but this was kept as an archive? You never know. > Purpose: always state the purpose of the code.. if it changes, than this should probably change. If it doesn't, than again: you must be doing your own thing. > Notes: optional, this is just notes that might be necessary..... again.. Notes to myself: I have some code in there that is not currently being used and if I go into production, I probably won't need it so may as well delete it. The Notes weren't supposed to be taken as a literal. This is just notes to anyone who reads the file. Sure, there is a such thing as too much commenting, but no one wants to go through the code to figure out what it does. Leaving a little comment up top of every page, regardless of the simplicity or complications of the function, it is just nice to leave for anyone who has to go in there. It's a better form of organization. Imagine having to go in there 3 years later... would you remember what it does? The little statement up top might help you remember more quickly.
deleted 9y ago
[deleted]
g051051 9y ago
Not only that, but if they wound up throwing away so much supposedly unmaintainable code, then he wasn't the great developer they thought he was.
- invisible 9y ago
  My feeling was that the spec they wrote and sold was "very hard." Rick neglected to push back (or did and was told too bad) and then the entire project was mismanaged. Maybe Rick was an asshole, but this post kind of blows my mind. I'm making some assumptions here but "two years" of delay isn't something one person causes (unless they're enabled to).
  - g051051 9y ago
    Exactly...what was going on for 2 years that they could slam out a replacement in just a few months?
- lucio 9y ago
  If he had the respect of his coworkers, I'm guessing "Rick" was really a 10x programmer, BADLY MANAGED. You need somebody else who understand the project objectives and can put a limit to the development of "configurable" options. >Rick’s product supported a dynamic workflow with over fifteen thousand permutations. In reality 99% of our use cases followed one of three paths. The team hard-coded the workflow. This removed over 30% of Rick’s work That's a failure of the manager, not the programmer. The good programmers, the ones who enjoy their work, will choose a complicated but beautiful path, will choose to make a configurable workflow whose configuration is itself configurable in LISP. It's the manager job to know that the workflow can be hard-coded and then avoid complexity by the love of complexity (good programmers love complexity solved by intricate and beautiful code). If not managed correctly, 10x programmers will choose the most complex, self-configurable solution where a hard-coded workflow will do. TL;DR: It seems a manager failure. Top talent needs top management in order to focus great creativity in the narrow path of productivity clients will pay for.
  - didibus 9y ago
threatofrain 9y ago
I also think it's kind of silly to criticize a solo developer for not documenting. Has anyone seen a mid-sized team that doesn't explicitly delegate or make documentation a priority? Now you expect a solo person to document?
- valuearb 9y ago
  I expect every professional developer to do at least the minimum necessary level of documenting, be they solo, small team, big team, startup, corporate, etc, etc.
- zzalpha 9y ago
  No developer is a solo developer. At a bare minimum, Present You is working with Future You. And Future You would appreciate it if Present You documented your work.
  - seanmcdirmid 9y ago
    The biggest problem of being a solo developer is that there is no one else to drive documentation needs. Yes, documentation would be great for future you, but present you has no one (including future you) to chat with about the code to get an idea of what documentation would be useful. If you are forced to work just inside your head, then the result is going to be obvious and predictable. And no, talking to the rubber ducky doesn't help.
    - mannykannot 9y ago
      on the contrary, many good developers do know what to write. They understand what the software does, and why, and they are capable of explaining it. They know what decisions were made, and why they were chosen over other options. Above all, they know where the tricky bits are (because they solved them), which are, for the most part, going to be the tricky bits for anyone following. Anything you talk to the rubber ducky about probably deserves writing down.
    - RangerScience 9y ago
projektir 9y ago
It's definitely tough to see what actually happened here from the outside.
imron 9y ago
This was my take as well. The guy was working 12 hours a day 7 days a week, with the fate of the entire project on his shoulders it's no wonder he turned in to 'Mr. Hyde'. Management should have stepped in long before it got to that stage.
zzalpha 9y ago
Ah, I see! So from one article and no actual evidence or information, a random Hacker News subscriber managed to determine that a story about a bad dev written by an insider on the project was actually about a poor, amazing, faultless dev who worked at the whim of Bad Management. Because, as we all know, Management Bad, Dev Good.
thisisit 9y ago
This thing reminded of a sketch I saw sometime ago: https://www.youtube.com/watch?v=BKorP55Aqvg https://www.youtube.com/watch?v=BKorP55Aqvg
- mercer 9y ago
  This gives me flashbacks...
mathattack 9y ago
Let's understand the context... The author has spent the last 10 years in University IT. Easy to see how it takes years to realize something is out of control and not managed well.
joshmn 9y ago
I agree. Maybe some of the developers weren't exactly up to snuff as well. Code — across an entire domain — typically doesn't vary as much in complexity as people's ability or knowledge can/would/does/is.
xxxdarrenxxx 9y ago
Also, this makes it sound like he'd do this out off ego. In fact, there's a likely chance he is his own worst enemy, really combatting his own perfectionism. Not to mention, when everyone tells you how smart you are, it feels good in the beginning, but after that compliments can be interpreted as expectations and all the pressure that comes with it. One should have had (potentially 3rd party) come up to talk to him privately months prior to that and adress his motivation. Ideally this is for the hiring interview itself, but re evaluating once a year is a more healthy prospect for both the company and the worker. "Rick" might feel great, but by dropping based on something that is so tied to his identity could be very painfull for him nonetheless. Not going to judge, you should always hold the company as a whole before the individual imo, but there are more amicable ways to do so
mannykannot 9y ago
Firstly, I don't see this guy being scapegoated - he appears to have been given the option of being part of the solution, but refused, and he appears to have worked himself into a corner by refusing to work with anyone. More generally, while I don't know any more about this case than what is in the article, I have seen something matching the description given here, and the situation there was not as you describe, except in that the fault lay both in the developer and his managers. He thought he was an exceptional developer and he was going to prove it by writing really complex code, even if the application did not need it (he did not, of course, describe it as complex - it was, in his mind, elegant, object-oriented (it was a time when that was still the one true way), efficient, reusable... but in reality, it was mostly a mixture of unnecessarily complex and confused.) Naturally, he was averse to working with morons who could not immediately follow what he was doing, so he worked alone, obsessively, and incessantly. As time went by, more of his explanations for why some feature could not be made available now were based on the complexity he had introduced earlier in the process. Management takes the blame for allowing this situation to develop. His initial managers were insecure about their technical ability, and deferred to his judgement - it was a case study in why technical managers need technical knowledge (to be fair, they were also snowed by a load of non-technical responsibilities that sucked up the time for running the project.) In the end, he precipitated the issue by resigning (presumably, he had found some other manager impressed by his apparent mastery of all things technical.) By then, I had moved on and I don't know it ended up.

pdwetz 9y ago

Also, I'm not sure I'd apply the label "genius" with someone who has copious amounts of "copy pasta" in his solely crafted code base.

imustbeevil 9y ago
Makes you wonder why the company would consider him their "top talent".
- zeveb 9y ago
  I imagine that it's because he delivered, rather than taking the time to abstract away stuff which might not need to be abstracted away. Remember that very, very few organisations (companies or in academia) have 'quality code' as an overarching goal: rather, they want good enough code, soon. Time after time I've seen developers fall into one of two traps: abstracting too soon or too late. It's very, very difficult to avoid. My preferred method is to just hack together something that works over a couple of iterations, then spend an iteration refactoring. It's hard to convince a business that this refactoring time isn't wasted, but it is in fact extremely valuable to the code base. 'I need to do this now so that I can satisfy your change requests later' sometimes works.

mattbgates 9y ago

I think I have to agree with you. The fact that Rick was allowed to be turned from a Dr. Jekyll to a Mr. Hyde is kind of the company's fault. No one stepped in to hold Rick accountable during meetings? While I no longer work there, my first job with some programming had me training to understand the code, what it was about, and even how to write it. To this day, I still use this method so I don't get lost or bored in my code. These are the lines I actually use along with commenting my own code just in case I have to return back to it weeks or months or even years later, I don't have to try and trace every step back to a particular code. // AUTHOR: MG // FILENAME: functions.php // STATUS: ACTIVE // PURPOSE: All of the functions for this application (app name) // NOTES: There are several unused functions in this file that are commented out but once in production // They can be deleted as we likely will not be needing them at all. Those 5 lines have saved me a lot of time. While I don't include the "author" line since it just me writing the code, if there are tons of hands in there, you should know EVERY SINGLE author as well as when code gets commented, it should contain the initials upfront, such as // mg: this does this and this does that. If I know multiple files touch.. I also add: "ASSOCIATIONS:" and list all files that call this one. Using this method, I've been able to complete a bunch of projects much quicker because any time I start to forget: what am I doing? what does this code do? am I on the right track? I can look right at the beginning of a file and know the answer. I'm not saying that a boss or supervisor has to be a micromanager, but meetings are necessary to understand where everyone is at. Leaving a programmer to do his own thing means that he really is doing his own thing and is more likely to get lost in the code. I'd say more like he wasn't a genius but thought he could do it alone.. and sometimes, it is nice to have someone step in and tell you: "Hey where we at? What can we do to speed this up?" or even provide their own insight... I can't tell you how many times I've talked with my spouse about an issue.. and she's suggested, "Why don't you just do this?" and it has saved me hours of time just because of someone not in the code is able to see another solution.

Avalaxy 9y ago
> AUTHOR: MG This is already in your commit history, so why hardcode it into the source? > FILENAME: functions.php This is obvious because you just opened the file. So again, why even put it there? When the file gets renamed the documentation is no longer correct? These things are also hard to refactor. > STATUS: ACTIVE Every part of the code is always active... > PURPOSE: All of the functions for this application (app name) Okay, probably the most useful one here. But what if we're refactoring the code and the purpose changes? Or if someone adds a few functions and the documentation no longer covers the purpose? > NOTES: There are several unused functions in this file that are commented out but once in production They can be deleted as we likely will not be needing them at all. Very dangerous, again because the source might change while the documentation doesn't. But why even write "they can be deleted"? Why not just delete them? That's what version control is for.
- nowbacktowork 9y ago
  I'm not sure why you're being down voted, but this is a very reasonable counter point. The purpose or brief should be at the top of every file, it should also evolve as class or implementation does. Arguable that it's really the only one that matters and can also come from no other tool or location.
- mattbgates 9y ago
  Avalaxy, while I know companies use tools to do their thing... I don't, I'm old school. I have files on an FTP server and I write PHP code. But to explain: > Author: completely optional, depends on what you are using, you aren't wrong.. since I'm old fashioned, if I were to hire some coder to help me maintain my programs, I'd like to know that he was in there, and I'd have no way of knowing.. again, probably not anyone's issue, but I'm old fashion. > Status: Not all files are in use, but sometimes they are just leftover and may not be deleted, or sometimes, they might be used for testing purposes -- so Status can be changed to INACTIVE, TESTING PURPOSES ONLY, etc. Maybe the file is inactive because newer code was written, but this was kept as an archive? You never know. > Purpose: always state the purpose of the code.. if it changes, than this should probably change. If it doesn't, than again: you must be doing your own thing. > Notes: optional, this is just notes that might be necessary..... again.. Notes to myself: I have some code in there that is not currently being used and if I go into production, I probably won't need it so may as well delete it. The Notes weren't supposed to be taken as a literal. This is just notes to anyone who reads the file. Sure, there is a such thing as too much commenting, but no one wants to go through the code to figure out what it does. Leaving a little comment up top of every page, regardless of the simplicity or complications of the function, it is just nice to leave for anyone who has to go in there. It's a better form of organization. Imagine having to go in there 3 years later... would you remember what it does? The little statement up top might help you remember more quickly.

deleted 9y ago

[deleted]

g051051 9y ago

Not only that, but if they wound up throwing away so much supposedly unmaintainable code, then he wasn't the great developer they thought he was.

invisible 9y ago
My feeling was that the spec they wrote and sold was "very hard." Rick neglected to push back (or did and was told too bad) and then the entire project was mismanaged. Maybe Rick was an asshole, but this post kind of blows my mind. I'm making some assumptions here but "two years" of delay isn't something one person causes (unless they're enabled to).
- g051051 9y ago
  Exactly...what was going on for 2 years that they could slam out a replacement in just a few months?
lucio 9y ago
If he had the respect of his coworkers, I'm guessing "Rick" was really a 10x programmer, BADLY MANAGED. You need somebody else who understand the project objectives and can put a limit to the development of "configurable" options. >Rick’s product supported a dynamic workflow with over fifteen thousand permutations. In reality 99% of our use cases followed one of three paths. The team hard-coded the workflow. This removed over 30% of Rick’s work That's a failure of the manager, not the programmer. The good programmers, the ones who enjoy their work, will choose a complicated but beautiful path, will choose to make a configurable workflow whose configuration is itself configurable in LISP. It's the manager job to know that the workflow can be hard-coded and then avoid complexity by the love of complexity (good programmers love complexity solved by intricate and beautiful code). If not managed correctly, 10x programmers will choose the most complex, self-configurable solution where a hard-coded workflow will do. TL;DR: It seems a manager failure. Top talent needs top management in order to focus great creativity in the narrow path of productivity clients will pay for.
- didibus 9y ago

threatofrain 9y ago

I also think it's kind of silly to criticize a solo developer for not documenting. Has anyone seen a mid-sized team that doesn't explicitly delegate or make documentation a priority? Now you expect a solo person to document?

valuearb 9y ago
I expect every professional developer to do at least the minimum necessary level of documenting, be they solo, small team, big team, startup, corporate, etc, etc.
zzalpha 9y ago
No developer is a solo developer. At a bare minimum, Present You is working with Future You. And Future You would appreciate it if Present You documented your work.
- seanmcdirmid 9y ago
  The biggest problem of being a solo developer is that there is no one else to drive documentation needs. Yes, documentation would be great for future you, but present you has no one (including future you) to chat with about the code to get an idea of what documentation would be useful. If you are forced to work just inside your head, then the result is going to be obvious and predictable. And no, talking to the rubber ducky doesn't help.
  - mannykannot 9y ago
    on the contrary, many good developers do know what to write. They understand what the software does, and why, and they are capable of explaining it. They know what decisions were made, and why they were chosen over other options. Above all, they know where the tricky bits are (because they solved them), which are, for the most part, going to be the tricky bits for anyone following. Anything you talk to the rubber ducky about probably deserves writing down.
  - RangerScience 9y ago

projektir 9y ago

It's definitely tough to see what actually happened here from the outside.

imron 9y ago

This was my take as well. The guy was working 12 hours a day 7 days a week, with the fate of the entire project on his shoulders it's no wonder he turned in to 'Mr. Hyde'. Management should have stepped in long before it got to that stage.

zzalpha 9y ago

Ah, I see! So from one article and no actual evidence or information, a random Hacker News subscriber managed to determine that a story about a bad dev written by an insider on the project was actually about a poor, amazing, faultless dev who worked at the whim of Bad Management. Because, as we all know, Management Bad, Dev Good.

thisisit 9y ago

This thing reminded of a sketch I saw sometime ago: https://www.youtube.com/watch?v=BKorP55Aqvg https://www.youtube.com/watch?v=BKorP55Aqvg

mercer 9y ago
This gives me flashbacks...

mathattack 9y ago

Let's understand the context... The author has spent the last 10 years in University IT. Easy to see how it takes years to realize something is out of control and not managed well.

joshmn 9y ago

I agree. Maybe some of the developers weren't exactly up to snuff as well. Code — across an entire domain — typically doesn't vary as much in complexity as people's ability or knowledge can/would/does/is.

xxxdarrenxxx 9y ago

Also, this makes it sound like he'd do this out off ego. In fact, there's a likely chance he is his own worst enemy, really combatting his own perfectionism. Not to mention, when everyone tells you how smart you are, it feels good in the beginning, but after that compliments can be interpreted as expectations and all the pressure that comes with it. One should have had (potentially 3rd party) come up to talk to him privately months prior to that and adress his motivation. Ideally this is for the hiring interview itself, but re evaluating once a year is a more healthy prospect for both the company and the worker. "Rick" might feel great, but by dropping based on something that is so tied to his identity could be very painfull for him nonetheless. Not going to judge, you should always hold the company as a whole before the individual imo, but there are more amicable ways to do so

mannykannot 9y ago

Firstly, I don't see this guy being scapegoated - he appears to have been given the option of being part of the solution, but refused, and he appears to have worked himself into a corner by refusing to work with anyone. More generally, while I don't know any more about this case than what is in the article, I have seen something matching the description given here, and the situation there was not as you describe, except in that the fault lay both in the developer and his managers. He thought he was an exceptional developer and he was going to prove it by writing really complex code, even if the application did not need it (he did not, of course, describe it as complex - it was, in his mind, elegant, object-oriented (it was a time when that was still the one true way), efficient, reusable... but in reality, it was mostly a mixture of unnecessarily complex and confused.) Naturally, he was averse to working with morons who could not immediately follow what he was doing, so he worked alone, obsessively, and incessantly. As time went by, more of his explanations for why some feature could not be made available now were based on the complexity he had introduced earlier in the process. Management takes the blame for allowing this situation to develop. His initial managers were insecure about their technical ability, and deferred to his judgement - it was a case study in why technical managers need technical knowledge (to be fair, they were also snowed by a load of non-technical responsibilities that sucked up the time for running the project.) In the end, he precipitated the issue by resigning (presumably, he had found some other manager impressed by his apparent mastery of all things technical.) By then, I had moved on and I don't know it ended up.