71–80 of 137 posts
If management were better and kept better tabs on Rick, they could have nipped this in the bud. Sounds like they instead let this fester until it turned into an untenable situation.
This sort of thing is often seen in companies where the top management are not that technical. They employ "geniuses" who are in fact just idiots, but are so intimidated and awed by the ego that they are afraid to call them on their bad behaviour. Even better, not employ such people in the first place.
I think such people should be given a direct talking to about their behaviour, given the chance to fix it, and if not, moved on.
I've dealt with many companies who are tip toeing around whilst trying to work out how to employ someone to replace this toxic team member.
Earlier quoted context omitted.
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.
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 rem…
Anyway IMO you have more like 4 types of dev, the ones who fail to write fizzbuzz, the ones who can do the vast majority of what they are asked, the ones that can do everything and can self manage and stay focused on (and clarify) product requirements (probably what you mean by 10x) and the ones that have highly specialized skills (e.g. ML, graphics, embedded systems, etc).
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 becaus…
Earlier quoted context omitted.
> Avalaxy, while I know companies use tools to do their thing... I don't, I'm old school. You would do well to learn source control system (which these days basically means git). Leaving aside the team/collaboration part, once you learn it, it's so incredibly freeing. I cannot understate this enough. You can make changes to the code, and then go back with one operation (discard changes). You can work on an experiment…
I do know what "source control" is but even when I wasn't working for myself, my boss made me still add this stuff, despite knowing at the end, upon saving, it would ask what changes were made. We used something called "Source Safe" from Microsoft. As for what's in the Notes and deleting it upon live production... that is the old stuff... in case the new stuff stopped working for whatever reason. I guess we all have…
Earlier quoted context omitted.
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.
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 rem…
I see this as a programmer responsibility... how is the manager even supposed to know whether it's hard-codeable?
The trouble is often that the programmer doesn't get enough information to make this decision, but that's a different story.
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 becaus…
Management should have stepped in long before it got to that stage.
[1] https://medium.com/@peachpie/thanks-for-the-insightful-respo...
Earlier quoted context omitted.
> 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 (a…
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 anyo…
None of that prevents you from using source control.