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."
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.
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.
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.
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.
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.
To assume "at the code level it should be largely self-documenting" is to be a Rick. Comments are there to help everyone, including non-programmers understand what is going on.
What am I to make from: "while I know companies use tools to do their thing... I don't", if not that you're not using a version control tool?
It's not "genius behavior", but well accepted from people like Uncle Bob, that documentation should be in the names of small and focused functions, methods or classes, not in comments.
I have been coding for almost 40 years and always been big on documenting code, but the problem is that code changes and documentation doesn’t always keep up.
Given modern tools I’ve come to the conclusion that documenting overall purpose and specific edge cases is more than enough. For example, the file header should describe its purpose, and anything in the actual code that’s not obvious should be commented. No more boilerplate function or file comment header. Git tells me who wrote each line of code, I know the name of the funcs and files, and I can see the inputs/outputs for every func with my own two eyes.
> I have been coding for almost 40 years and always been big on documenting code, but the problem is that code changes and documentation doesn’t always keep up.
This has always been a sign for me to tread very, very carefully. People who change code without changing the comments probably didn't read the comments, didn't read the code or didn't understand it - either way, if comment and code disagree both are probably wrong.
I agree mismatched comments/code is a huge warning sign. But I think requiring standardized comments is a problem.
When I started out every function had to have a header comment, with name, inputs/outputs, description of purpose/etc. It was significant extra work to keep that up to date. I could update a function three times in a day, and have to rewrite the comments three times to check it in.
And in the end, I know the name of the function. I can see the inputs and outputs. The only part of those comments that were occasionally useful were purpose, details of which often changed with edits. And in reality, as long as the function isn't hundreds of lines long (another problem), I can read it and discern exactly what it's trying to do.
Comments that were most useful said stuff like "this looks weird or dumb, but we had to do it this way because of this thing we and you probably didn't expect in the data/system/etc"
You said initially companies have their tools and you don't. Later you went on about simply using ftp and coding php. It sure seems like you don't use version control. At least not at a level that it should be used at in this day and age.
For what logical purpose would a non-programmer be reading your source code and only be able to accomplish whatever their task is if you adequately comment it?
> 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 experimental idea (in a branch) for a few days/hours, then switch back to your main code to fix an important bug, go back and finish your experimental branch eventually, and merge everything together -- often with nearly zero effort. If you're supporting multiple release versions at once, you can fix a bug in one and often easily apply it to all other versions.
Ever have a situation where something just stops working, but you're not sure when other than in worked four months ago? You can arbitrarily check out any old version and test, and even - in a single operation - undo that change from the current version of code.
Can you do all this without source control (or with copies named by date)? Sure, but it's kind of like the difference between fetching water from a well using a hand pump and bucket vs having running water and being able to open a tap. Before you have running water, it's just life, and it's not that big a deal to fetch water, really. Once you have it, you could never imagine having to live life that way.
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 our own methods of doing things. Fortunately, I've not had major issues, though everything is backed up to it a server upon my completion of work for the day.
Your status reasoning seems weak. Archive? Version control will have it in history. Maybe rarely you want it around for active references. Otherwise you likely don't need it.
The author bit is solved with version control. Much better than a line that can get bogged down with multiple authors or be outdated.
It doesn't feel like you're being old fashioned or old school. It seems like you're being a bit stubborn in your ways. Version control is a good thing. Perhaps there's better ways. Going your way with not having an sort of real alternative isn't right though.
Your other reasons like coming back years later can be applied to version control too. It's helpful to have commits that have diffs, time stamps, author, and other meta data. Imagine having to come back 3 years later without any of that. Commit history might help you remember and manage your project more quickly, efficiently, and effectively.
I will have to admit that this GIT/SVN is a very elegant solution in the ideal world, but in my experience real world code gets very very messy. Teams get lazy and don't always give very detailed commenting in version control.
Startups may be better at this, but the corporate world is even messier with quick turned spaghetti code. Any markup in the codebase itself helps the next developer tremendously.
Personally, I find @mattbgates best practice to be very justifiable in practical use.
Why don't you use source control instead.
Don't say who you are in the comments, that's what "blame" is for. Don't comment code, delete it, it won't be lost since you have a history. Make a branch for your experiments if you have to. The state of your work should be apparent in the bugtracker.
Code comments are code comments. If you use comments to help with your development process, there is probably some work to do with your toolchain. Good source control and a bugtracker are a must.
/**
* Calculate the thing.
*
* @param $foo the foo value
* @param $bar the bar value
* @return the thing
*/
function calculateThing($foo, $bar) {
return $foo + $bar; // add foo and bar
}
Such comments are worthless noise that obscures the important parts of the code and camouflages any actual useful comments that might be there. I would so much rather have better names than "thing", "foo", and "bar", and maybe a comment about why the values are summed, if it's not obvious. When you do those right, you won't even need many comments. Maybe a docblock, but don't bother with that if it's nothing more than a robotic "English version" of what is already obvious from the function definition. IMO most good developers will perceive your file header as a redundant annoyance for similar reasons, as other commentors have explained.
It's the "CS 050 Computer Science for Humanities Majors" type of commenting (I was a humanities major, no offense intended). A bunch of comments that are only there because you think you have to have comments, or because you're graded on whether or not comments exist.
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).
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.
I've seen a lot of clients and managers ask for infinitely configurable software more often them I've seen devs introduce it as unnecessary complexity. It's often asked by businesses in the hope that afterwards all change are free and don't require a dev to make. Futile for sure, I constantly have to tell the business why that's not sane, and that they actually don't have that many use cases.
I think you misunderstand what "10x programmer" is intended to mean (even though I hate this term and think it is mostly rubbish). A 10x wouldn't make some ungoldly amount of complexity "just because", they would implement the simplest solution that meets the given requirements - hence they're "10x more productive" than other developers; this doesn't mean 10x LOC, just being pragmatic. The ones you describe are the non-10x.
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).
Also a 10x Dev would usually go back to the product manager/client and say that feature X looks kind of redundant or a really edge case, but would take a significant chunk of time to code. Is it really needed for v1.0 considering it will cost 2 weeks of Dev Time?
You obviously need to have a good understanding of your clients and their needs and the way they use your product to e able to do that, but many shops simply ignore introducing their developers to the actual users of the product.
> 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).
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.
The buck stops with the manager. Every time. Only a poor carpenter blames his tools and people are a managers tools.
If a carpenter doesn't pay attention and a sharp saw cuts their hand off or ruins an expensive piece of wood maybe they need training in how to run saws. Or perhaps they just need less powerful saws until they get more experience.
Management is a lot more than going to meetings and ordering people around. The ability to successfully staff and orchestrate a project is no small skill and one can't just jump in and expect success. Lot of people think they can do it, but there are very few really good managers in my experience. Most are hacks who can't actually do the job and don't even understand what it entails. As evidenced by the article.
> good programmers love complexity solved by intricate and beautiful code.
I can't speak for good programmers, but while I admire elegant and insightful solutions where possible, for the other 99% of the cases I prefer the simplest effective solution (and with simple definitions of 'simple').
A good programmer solves the given problem in the most simple, decoupled, way possible. Their solution will inevitably be easy for other devs to jump in and understand and work one with breaking the rest of the code base.
Sounds like they graded him on feature completion rather than how he implemented the features. It's a one sided story though. I've seen projects fail due to constantly "rearranging the furniture."
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?
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.
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.
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.
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.
I use "tired me". I think once or twice I've used "inebriated me".
In the beginning of my career I was much more diligent about this (but I also didn't write as readable code, so it was more necessary); the exercise was simple:
When I hit the stupid part of the day (the end of the day), I go back over code. When I don't understand something, I write down something about my confusion. In the morning, when I'm back to being smart, I convert all the confusion to comments and/or better code.
Yes, unless it is single-use code. Otherwise, if the person is only developing for himself, he can choose whether or not to write any documentation, but if he is sensible, he will write something.
It is moot anyway, as he was not supposed to be a solo developer.
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.
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.
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.
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.
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
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.
Rick was not managed - at all. Rick became a monster because no one at the management layer was doing their job. If you're letting coders write custom tools instead of procuring where possible, that's management's fault. The list of mismanagement goes on and on. Sure Rick was a douchebag. Anyone who has spent any time in a cs program has met a potential Rick. The fact that you fostered one while he almost blew up your project is your failure, not his.
Edit: also if 90% of his code was able to be thrown out, then I don't think Rick was ever the super star that you or he thought he was.
I've seen this sort of thing happen before, and I think there's a big danger in leaving senior engineers lonely in a company.
Imagine how differently this would have played out if 'Rick' had someone at their technical level to talk to. They could bounce ideas off another person and they could help field questions from the team when busy. It sounds like Rick made some potentially questionable technical decisions - but with another very experienced dev around they could keep each other honest and on point.
The problems that come from having only 1 junior dev on the team are obvious - that person will feel alone and out of their depth, and like they're bothering everyone with their problems. But there are similar issues from having only 1 senior dev on a team. That person will naturally try to take responsibility for every aspect of your technology stack. They will do that naturally because the only other option they will see is to let mistakes slip in to the product. And a technical leadership position is a leadership position. Being a good technical leader requires time away from programming to mentor, code review and brainstorm. It requires you to hold meetings, support your team and keep others accountable to standards. The people side of that is a set of skills many programmers don't have.
Ultimately by firing that person you're saying that your team cohesion is more important than quality in the product. Thats a totally reasonable choice. Its also an option that a skilled manager would be able to bring Rick on board with. "Hey Rick, over the long term we want to build an amazing team. You're the most skilled person we have, and we think in the long run the mentoring you've been doing is going to provide more value than getting this particular iteration of our product out the door. We want you in on the long term vision of our company having great engineering, which might mean this next release slips - but we think extra mentoring will be worth it. What do you think?" ... Etc.
I suspect what happened here was Rick was the type of personality that defined himself by being the person who solved problems. He probably wasn't a genius, he was probably just senior and experienced.
He didn't want it to end up like this, I bet. I bet he didn't expect it. He didn't know how to say no, and even worse: no one knew that he should. Rick had no peers or management that could even faintly empathize. They didn't get that there was simply too much to do.
Rick's first and biggest mistake was long before his absurd outbursts: refusing to admit the project was too big before it was too late. Instead he imploded and started saying stupid and offensive things. He defined his identity by his ability to solve problems but no matter how much he tried, the problem seemed to get worse.
He got fired. He even deserved to be fired, I think. Because part of being the technical adult in the room is NOT letting it get that far out of control.
The ugly part is that it seems no real lessons have been leared by the org. Instead of recognizing the obvious lack of technical management, they're spreading the responsibility across the entire org. Intead of owning their business logic they called up vendors and sold it to them. Instead of broading the scope of the business with these added capabilities early on the entire business is now balanced on top of a pinhead of those few cases.
Everyone made terrible mistakes. And it seems like no one learned from them.
Eh, I've joined 3 or 4 projects where there was a "genius" behind it.
They liked being in control, and to a one they all talked about being irreplaceable.
I don't know Rick, of course, and can't speculate on what's going on in his head, but he certainly seems like the geniuses on the projects I and others ended up rescuing from their own respective geniuses.
I think everyone's quick to pile on the author, for some reason, but the Rick side of the story just rings so many bells for failing projects I've joined (or, later on, took over and reimplemented by myself).
I'm no genius, either, just old enough to know a little tiny bit better.
Ok, fair, that's good, I think we probably agree more than disagree then.
I guess my take on it is that the handful of Ricks I've seen, they all wanted to position themselves as irreplaceable, as kings of the project. For them it was intentional.
Maybe not the case with the Rick in this story. Without knowing the person (or even if the person is real, or if this is a composite character from multiple situations, etc), we're all just guessing.
I'm just more inclined to sympathize with the author, because of my own experiences with Ricks. :)
I think everyone's quick to pile on the author, for some reason
Oh, that's easy.
The prevailing wisdom around here is that management is always, without fail, a bad thing.
Management is either bad because they get in the way by doing anything, or, when a project goes sideways, management is bad because it failed at doing something.
For example, the devs involved in the BMW scandal? Well management told them what to do, so it's management's fault.
And this post? Well, it's management's fault for not stopping this guy.
"Multi-year management failures result in huge time and resource company expenses".
Outside of that, I'd also fire the person that wrote the article on company image tarnishing grounds.
He may be proud of his decision, and it may have been the right thing to do, but considering what he wrote publicly, anybody sane would stay away from them now.
From the way they described the developer and his work habits, it doesn't look like they have a good idea of what "top talent" means. Probably one of those places where you have to look busy and act smart to get promoted vs. actually producing results.
Exactly. There is nothing inherently wrong with a single developer building an entire product, and I know a lot of very good "10x" developers who work mostly on their own and build great products.
The reality is that there really are a lot of 10x developers out there, but there are also 0.1x developers like this guy, who actively sabotage projects.
The author has the audacity to lay 100% of the blame at the feet of his "genius". Sadly, the author will run continually into new sets of problems again and again at his company and each time find a new scapegoat. This is because 1) he cannot recognize that he is the problem and 2) attacks those who has scapegoated in public.
Until the author matures, employees would be wise to run in the opposite direction. If they don't the next article will be about one of them.
Well, I think the "genius" deserves most of the blame. The company obviously shouldn't have allowed this guy to waste 2 years writing crap, but I don't think it's fair to say that the author of this article is "the problem". That's like blaming someone for hiring an incompetent builder to build their house.
The author is not to blame for the problem of course - since the problem existed before his arrival. The author made the problem worse by implementing the wrong solution. The company was lucky to survive this misstep, and poor Rick was forced to work insane hours just to end up being fired anyway. Not a good outcome for anyone.
The company looks bad for mistreating a seriously committed employee.
Rick looks bad because the author decided to slag him off in a public blog post
The author looks bad because he's oblivious to what he's done and instead decided to shit on a really dedicated employee for the failures of the management team.
It takes some serious lack of perspective to post something like this on your public blog. Ugh. I feel sick.
>The author made the problem worse by implementing the wrong solution
From what I can tell, the author thoroughly investigated the situation, then made the (correct) decision to rewrite the entire thing from scratch.
It does seem as if Rick was severely burned out from the long hours, which probably made things a lot worse. I think he shares equal blame along with the company...nobody asked him to do that, and it seems to have been mostly caused by Rick himself. The company should have pulled the plug earlier, but they must have trusted him.
I agree it's probably a bad idea to post it publically.
> I agree it's probably a bad idea to post it publicly.
This. I completely agree with you here. I would take it a large step further and say it was a despicable idea, particularly in the manner it was published as "Best decision ever". Yes, letting the guy go was a good decision and a good correction to a big, expensive, problem. Best decision? Far from it. It was a correction to a massive failure that amounts to paying a few hundred grand, letting a problem fester too long and finally stepping in and "starting over".
Worse, though, is that they've maligned someone in the process. Yes, "Rick" was anonymous ... except to Rick, Rick's family and friends, and probably prospective employers who will know where Rick last worked, who will know he was "let go" from his last job, and who will hit up Google, happen upon this post, bin his resume and pat themselves on the back for dodging a bullet.
Never mind that they've presented exactly one side of a complicated story with all of the biases that come into that. Never mind that a large number of the comments here are from people who correctly suspect that maybe there's something about this organization that caused this massive failure to happen and that those things, whatever they are, might have contributed to Rick failing in his position. And never mind that Rick, now that he's had a bit of an opportunity to reflect, has (hopefully) figured out some of the things he should have done differently and has (hopefully) made positive life changes that will likely cause him to be a fine employee in the future. Or the fact that he might just have not been a terribly good fit there in the first place and could thrive very well elsewhere. The person landing on this post, using basic deductive skills to decide "Candidate X is Rick", will pat themselves on the back for avoiding hiring the developer equivalent of a BOFH. Of course, this company will inevitably lay some other male employee someone off in the future for reasons that are not the employee's fault, and now they might be assumed to be "Rick". There was a small benefit to the world-at-large for them having written this, but it came with huge downsides in the manner in which they've shared.
They could have written the piece as an argument with hypothetical components strewn throughout in more of a philosophical manner including no anecdotal stories about former employees and provided the same benefits, but without the myriad of downsides. It might not have been as interesting of a read, or reached as large of an audience, but then is the conclusion they've drawn really all that mind-blowing? The story, summed up, amounts to "We spent a large amount of money on someone and after two years of continuing to spend that money, we realized that we would have been better off if we had just decided to not work on that project and had, instead, turned that money into cash and flushed it all down the toilet[0]. So we stopped spending that money. Best. Decision. Evar. /s"
[0] Because every once in a while the toilet will plug, and some of that money will come back up.
This is what I was thinking about. The whole post just seems petty. You don't want indispensable employees unless you know how to manage them. Instead of acknowledging that mistake, just going on to pat yourself on the back for pisspoor management is just disgusting.
> That's like blaming someone for hiring an incompetent builder to build their house.
Well, kinda, but kinda not, too. When people hire builders they often know little/nothing about building a house and have a limited understanding of what quality building looks like. This company, hopefully, knew what habits a good programmer has (they must have because they eventually realized he didn't have them). Using your analogy, it'd be like a builder hiring a sub-contractor, relying on that sub-contractor to build the house in its entirety, allowing that sub-contractor to slip on the deadline by two years and when the builder went to check up on the sub-contractor, they discover the property has a kitchen, a foyer, a bunch of bedrooms but no roof or walls.
Note that I'm not saying my analogy fits perfectly, nor that "Rick" was actually the negligent builder he's been painted out to be in this but it was as much a failure on the company's side especially when you consider that they've paid this individual for those years of work knowing that it's non-refundable, they're stuck with the house, and the only option they now have is to bulldoze the property and start over. A better approach would have been to step in much earlier and correct "Rick" or get rid of him before a two-year slip in a project could occur.
This looks like gross mismanagement. Gross mismanagement of client expectation, gross mismanagement of product scope, gross mismanagement of feature/engineering processes/schedule, lack of leadership, and worst of all, gross mismanagement of talent. It sounds like management has no or very little technical background. Didn't understand how to build the product or translate requested features into feasible functionality. And simply thrust the whole problem onto a single senior developer. The guy while talented was overwork and exhausted. I would turn into a Mr. Hyde too if I have to work seven-day weeks, twelve hours a day.
>Your team’s strength is not a function of the talent of individual members. It’s a function of their collaboration, tenacity, and mutual respect.
It's both. Don't fall into the trap that collaboration, tenacity and mutual respect will compensate for lack of talent. You still need to find talented people, just don't hire assholes or turn them into assholes.
I think another issue that may be worth mentioning is that a lot of the articles in the freeCodeCamp publication are written specifically to appeal to people who are not (yet) very skilled.
At least in this particular case, the combination of the red flags already mentioned by many together with the demographics of the target audience seems like a dangerous combination that promotes stigmatisation of "talents" and the idea of "if you can't become it or work with it, kill it".
I may be reading between the lines a bit too much, but the article appears to be exceedingly popular by the freeCodeCamp publication standards, and that, to me, is very unsettling for a story that I think is effectively "management turned mismanagement into a heroic triumph".
Everyone is commenting on the mismanagement angle here, which is very real, but I think it's also important to point out that the author is simply wrong about "Rick" being a genius if the descriptions of his behavior and work product are accurate. I think there's a huge myth about solitary geniuses who are assholes. I've yet to meet someone I consider really genius who is also a toxic asshole. Maybe occasionally you run into geniuses who are a little shy or socially awkward, but by and large the defining factors of the true geniuses I've worked with have always been a desire to share with the team, improve everyone around them and contribute deeply to the product. Their code is maintainable and other engineers totally get it and when they don't the genius is there to walk them through it, taking notes on how they can make it easier to understand next time. They hate the idea of being a dependency/SPOF, and they are extremely accountable for very real and obvious progress.
I've also worked with people genuinely like "Rick" from the article. It usually takes about a week to find out that they don't actually write any code or contribute to the team in any meaningful way besides making noise. People who are that wrapped up in their own ego cannot make meaningful contributions to their teams.
It lends more weight to the idea that there was a ton of mismanagement going on at this company that beyond the bullshit described in the article, the author still considers "Rick" to be a genius.
I find that brilliant people come from all walks of life. It's not obvious why you would think mental aptitude would translate to healthy, gentle, or sociable personalities.
Richard Feynman is known to have a temper, and Einstein was known to be extremely callous in intimate affairs. We've also seen MIT professors display a lesser regard for lesser minds in math. We've also seen brilliant top-of-their field sportsman display great arrogance and disregard to lessers. The guy who writes "The Haskell Book" isn't known to be nice, but people still acknowledge that it's one of the top texts. Linus Torvalds isn't known to be nice.
You might not consider these people to be "geniuses", but they are certainly brilliant in some way, participating heavily in their field in some way.
I'm sorry but you're making a massive stretch by implying the either Einstein or Feynman were known as toxic assholes by basically anyone (except maybe Einstein's wives).
And while one can of course say that someone is a genius at a sport, I meant specifically intellectually, and even more specifically I wanted to combat the notion that it is common for software engineers to be geniuses and total assholes. I just haven't seen that frequently, and in fact usually the pattern is that the engineers who are typical assholes are, correctly, the least secure in their own skills and try and mask that with needless complexity (in code, communication etc).
I guess maybe my meta point is that I think intelligence generally fights toxicity, not the opposite. I'm sure you can find counter examples as humans are complex.
> There are plenty of geniuses throughout history who were asseholes but still brilliant.
Agreed, as I said humans are complex and I'm sure you can find exceptions. Just talking about general trends here.
> EQ and IQ are not highly correlated at all.
Assuming by EQ you mean being a nice person and intelligence are not correlated I don't agree. Tons of studies backing this up (as well as correlation with overall happiness). Here are two:
EQ means emotional intelligence, the ability to empathize with people effectively, allowing people to take hints via social cues when they are being annoying or otherwise engaging in asshole-like behavior.
As geniuses are already extreme outliers. For one thing, they do not typically fit in very well with their peers, often leading to seemingly anti-social behavior.
None of the articles you link directly correlate EQ to intelligence, they corrleate it to civic minded ness, and getting good grades in school. Social people do well in social environments is not surprising.
If I were in charge of the people on the project I would ask for the paper trail to see what kind of methodology was being used to make progress.
I would probably end up finding that there was none (or only a bunch of CYA paper trails), and fire everyone who was involved in that project.
EDIT: I once was recruiting for a project I was working on, and one of the candidates during a phone interview bragged about a poorly managed project they were on that "wasn't their fault". I didn't address it, but that's where they were sorely mistaken. Not doing anything when you know there's a problem (even if you don't know what the problem is) is not a valid strategy IMO.
"Rick was churning out code faster than ever. He was working seven-day weeks, twelve hours a day.
..........................
Every day, Rick grew more belligerent and isolated. The mask was coming off. Jekyll was becoming Hyde."
Geezus. What kind of people are running this outfit that they don't see the connection between these two phenomenon?
People who haven't spent enough time around programmers and/or people who haven't spent a serious amount of time coding themselves would be my guess.
Coding 7 days a week 12 hours a day with the entire weight of everything on your shoulders while others have "meetings" and write Medium blog posts will turn Gandi into an asshole soon enough.
Not saying the guy wasn't intrinsically a jerk but this is a ridiculous failure of management. And you are posting about this ridiculous failure in an attempt to scapegoat someone who wasn't managed for the failure of a project that was poorly managed? Shame on you author. Seriously. Grow up.
While I understand that no one could have gotten to a better conclusion I find it a very distasteful commentary.
So Rick knew everything about the project, while everyone is simply making a living off his work all those months/years, saved the management face many times with miracles, probably not paid n*x, stopped attending meetings because no one understood the stuff anyway, and the author has bad opinion of Rick's code, conveniently ignoring context around Rick's choices, gleefully siding with all those managers who have no clue in the first place and fired the worker to have a new start!!!
Maybe Rick should be given a chance to comment on how bad those project savior choices were.
Now we need to wait and see when would they identify next Rick of the current version of the code when that stops cutting the muster for the flood of new requests.
Oh I hate Ricks. Programming genius who love to hear themselves speak, bully others into their technical decisions and refuses to be unwavered from predisposed technical biases. There is always some senior engineer with this attitude.
136 comments
[ 4.2 ms ] story [ 178 ms ] threadEveryone 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."
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.
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.
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.
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.
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.
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.
I agree with one of the parents that "Purpose" is probably the most useful, but even there: at that level the code should be largely self-documenting.
To assume "at the code level it should be largely self-documenting" is to be a Rick. Comments are there to help everyone, including non-programmers understand what is going on.
It's not "genius behavior", but well accepted from people like Uncle Bob, that documentation should be in the names of small and focused functions, methods or classes, not in comments.
You don't have to be a Rick to write clean, concise code.
I'd strongly recommend reading up:
http://www.codeodor.com/index.cfm/2008/6/18/Common-Excuses-U...
https://blog.codinghorror.com/coding-without-comments/
Given modern tools I’ve come to the conclusion that documenting overall purpose and specific edge cases is more than enough. For example, the file header should describe its purpose, and anything in the actual code that’s not obvious should be commented. No more boilerplate function or file comment header. Git tells me who wrote each line of code, I know the name of the funcs and files, and I can see the inputs/outputs for every func with my own two eyes.
This has always been a sign for me to tread very, very carefully. People who change code without changing the comments probably didn't read the comments, didn't read the code or didn't understand it - either way, if comment and code disagree both are probably wrong.
When I started out every function had to have a header comment, with name, inputs/outputs, description of purpose/etc. It was significant extra work to keep that up to date. I could update a function three times in a day, and have to rewrite the comments three times to check it in.
And in the end, I know the name of the function. I can see the inputs and outputs. The only part of those comments that were occasionally useful were purpose, details of which often changed with edits. And in reality, as long as the function isn't hundreds of lines long (another problem), I can read it and discern exactly what it's trying to do.
Comments that were most useful said stuff like "this looks weird or dumb, but we had to do it this way because of this thing we and you probably didn't expect in the data/system/etc"
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 experimental idea (in a branch) for a few days/hours, then switch back to your main code to fix an important bug, go back and finish your experimental branch eventually, and merge everything together -- often with nearly zero effort. If you're supporting multiple release versions at once, you can fix a bug in one and often easily apply it to all other versions.
Ever have a situation where something just stops working, but you're not sure when other than in worked four months ago? You can arbitrarily check out any old version and test, and even - in a single operation - undo that change from the current version of code.
Can you do all this without source control (or with copies named by date)? Sure, but it's kind of like the difference between fetching water from a well using a hand pump and bucket vs having running water and being able to open a tap. Before you have running water, it's just life, and it's not that big a deal to fetch water, really. Once you have it, you could never imagine having to live life that way.
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 our own methods of doing things. Fortunately, I've not had major issues, though everything is backed up to it a server upon my completion of work for the day.
The author bit is solved with version control. Much better than a line that can get bogged down with multiple authors or be outdated.
It doesn't feel like you're being old fashioned or old school. It seems like you're being a bit stubborn in your ways. Version control is a good thing. Perhaps there's better ways. Going your way with not having an sort of real alternative isn't right though.
Your other reasons like coming back years later can be applied to version control too. It's helpful to have commits that have diffs, time stamps, author, and other meta data. Imagine having to come back 3 years later without any of that. Commit history might help you remember and manage your project more quickly, efficiently, and effectively.
"Time Me, Gentlemen!"
https://www.theatlantic.com/health/archive/2012/10/time-me-g...
https://try.github.io/
It's not hard. It's not like you're computer illiterate and don't know how to program.
None of that prevents you from using source control.
Startups may be better at this, but the corporate world is even messier with quick turned spaghetti code. Any markup in the codebase itself helps the next developer tremendously.
Personally, I find @mattbgates best practice to be very justifiable in practical use.
Code comments are code comments. If you use comments to help with your development process, there is probably some work to do with your toolchain. Good source control and a bugtracker are a must.
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).
>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.
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).
You obviously need to have a good understanding of your clients and their needs and the way they use your product to e able to do that, but many shops simply ignore introducing their developers to the actual users of the product.
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.
If a carpenter doesn't pay attention and a sharp saw cuts their hand off or ruins an expensive piece of wood maybe they need training in how to run saws. Or perhaps they just need less powerful saws until they get more experience.
Management is a lot more than going to meetings and ordering people around. The ability to successfully staff and orchestrate a project is no small skill and one can't just jump in and expect success. Lot of people think they can do it, but there are very few really good managers in my experience. Most are hacks who can't actually do the job and don't even understand what it entails. As evidenced by the article.
I can't speak for good programmers, but while I admire elegant and insightful solutions where possible, for the other 99% of the cases I prefer the simplest effective solution (and with simple definitions of 'simple').
Now you expect a solo person to document?
And no, talking to the rubber ducky doesn't help.
Anything you talk to the rubber ducky about probably deserves writing down.
In the beginning of my career I was much more diligent about this (but I also didn't write as readable code, so it was more necessary); the exercise was simple:
When I hit the stupid part of the day (the end of the day), I go back over code. When I don't understand something, I write down something about my confusion. In the morning, when I'm back to being smart, I convert all the confusion to comments and/or better code.
Yes, unless it is single-use code. Otherwise, if the person is only developing for himself, he can choose whether or not to write any documentation, but if he is sensible, he will write something.
It is moot anyway, as he was not supposed to be a solo developer.
Management should have stepped in long before it got to that stage.
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.
https://www.youtube.com/watch?v=BKorP55Aqvg
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.
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
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.
Edit: also if 90% of his code was able to be thrown out, then I don't think Rick was ever the super star that you or he thought he was.
No one had the hard discussions with clients to reduce scope and cut high effort/low reward features?
They knew he was working 80 hour weeks and didn't take steps to address that early.
They did as soon as they had someone to blame, though.
Imagine how differently this would have played out if 'Rick' had someone at their technical level to talk to. They could bounce ideas off another person and they could help field questions from the team when busy. It sounds like Rick made some potentially questionable technical decisions - but with another very experienced dev around they could keep each other honest and on point.
The problems that come from having only 1 junior dev on the team are obvious - that person will feel alone and out of their depth, and like they're bothering everyone with their problems. But there are similar issues from having only 1 senior dev on a team. That person will naturally try to take responsibility for every aspect of your technology stack. They will do that naturally because the only other option they will see is to let mistakes slip in to the product. And a technical leadership position is a leadership position. Being a good technical leader requires time away from programming to mentor, code review and brainstorm. It requires you to hold meetings, support your team and keep others accountable to standards. The people side of that is a set of skills many programmers don't have.
Ultimately by firing that person you're saying that your team cohesion is more important than quality in the product. Thats a totally reasonable choice. Its also an option that a skilled manager would be able to bring Rick on board with. "Hey Rick, over the long term we want to build an amazing team. You're the most skilled person we have, and we think in the long run the mentoring you've been doing is going to provide more value than getting this particular iteration of our product out the door. We want you in on the long term vision of our company having great engineering, which might mean this next release slips - but we think extra mentoring will be worth it. What do you think?" ... Etc.
I suspect what happened here was Rick was the type of personality that defined himself by being the person who solved problems. He probably wasn't a genius, he was probably just senior and experienced.
He didn't want it to end up like this, I bet. I bet he didn't expect it. He didn't know how to say no, and even worse: no one knew that he should. Rick had no peers or management that could even faintly empathize. They didn't get that there was simply too much to do.
Rick's first and biggest mistake was long before his absurd outbursts: refusing to admit the project was too big before it was too late. Instead he imploded and started saying stupid and offensive things. He defined his identity by his ability to solve problems but no matter how much he tried, the problem seemed to get worse.
He got fired. He even deserved to be fired, I think. Because part of being the technical adult in the room is NOT letting it get that far out of control.
The ugly part is that it seems no real lessons have been leared by the org. Instead of recognizing the obvious lack of technical management, they're spreading the responsibility across the entire org. Intead of owning their business logic they called up vendors and sold it to them. Instead of broading the scope of the business with these added capabilities early on the entire business is now balanced on top of a pinhead of those few cases.
Everyone made terrible mistakes. And it seems like no one learned from them.
They liked being in control, and to a one they all talked about being irreplaceable.
I don't know Rick, of course, and can't speculate on what's going on in his head, but he certainly seems like the geniuses on the projects I and others ended up rescuing from their own respective geniuses.
I think everyone's quick to pile on the author, for some reason, but the Rick side of the story just rings so many bells for failing projects I've joined (or, later on, took over and reimplemented by myself).
I'm no genius, either, just old enough to know a little tiny bit better.
I guess my take on it is that the handful of Ricks I've seen, they all wanted to position themselves as irreplaceable, as kings of the project. For them it was intentional.
Maybe not the case with the Rick in this story. Without knowing the person (or even if the person is real, or if this is a composite character from multiple situations, etc), we're all just guessing.
I'm just more inclined to sympathize with the author, because of my own experiences with Ricks. :)
Oh, that's easy.
The prevailing wisdom around here is that management is always, without fail, a bad thing.
Management is either bad because they get in the way by doing anything, or, when a project goes sideways, management is bad because it failed at doing something.
For example, the devs involved in the BMW scandal? Well management told them what to do, so it's management's fault.
And this post? Well, it's management's fault for not stopping this guy.
But it's also this guy's fault for not being enough of a leader to avert the crisis.
I'm not sure how people read my post and say, "This is a story about how Rick was good or right."
"Multi-year management failures result in huge time and resource company expenses".
Outside of that, I'd also fire the person that wrote the article on company image tarnishing grounds.
He may be proud of his decision, and it may have been the right thing to do, but considering what he wrote publicly, anybody sane would stay away from them now.
The reality is that there really are a lot of 10x developers out there, but there are also 0.1x developers like this guy, who actively sabotage projects.
Until the author matures, employees would be wise to run in the opposite direction. If they don't the next article will be about one of them.
The company looks bad for mistreating a seriously committed employee.
Rick looks bad because the author decided to slag him off in a public blog post
The author looks bad because he's oblivious to what he's done and instead decided to shit on a really dedicated employee for the failures of the management team.
It takes some serious lack of perspective to post something like this on your public blog. Ugh. I feel sick.
From what I can tell, the author thoroughly investigated the situation, then made the (correct) decision to rewrite the entire thing from scratch.
It does seem as if Rick was severely burned out from the long hours, which probably made things a lot worse. I think he shares equal blame along with the company...nobody asked him to do that, and it seems to have been mostly caused by Rick himself. The company should have pulled the plug earlier, but they must have trusted him.
I agree it's probably a bad idea to post it publically.
This. I completely agree with you here. I would take it a large step further and say it was a despicable idea, particularly in the manner it was published as "Best decision ever". Yes, letting the guy go was a good decision and a good correction to a big, expensive, problem. Best decision? Far from it. It was a correction to a massive failure that amounts to paying a few hundred grand, letting a problem fester too long and finally stepping in and "starting over".
Worse, though, is that they've maligned someone in the process. Yes, "Rick" was anonymous ... except to Rick, Rick's family and friends, and probably prospective employers who will know where Rick last worked, who will know he was "let go" from his last job, and who will hit up Google, happen upon this post, bin his resume and pat themselves on the back for dodging a bullet.
Never mind that they've presented exactly one side of a complicated story with all of the biases that come into that. Never mind that a large number of the comments here are from people who correctly suspect that maybe there's something about this organization that caused this massive failure to happen and that those things, whatever they are, might have contributed to Rick failing in his position. And never mind that Rick, now that he's had a bit of an opportunity to reflect, has (hopefully) figured out some of the things he should have done differently and has (hopefully) made positive life changes that will likely cause him to be a fine employee in the future. Or the fact that he might just have not been a terribly good fit there in the first place and could thrive very well elsewhere. The person landing on this post, using basic deductive skills to decide "Candidate X is Rick", will pat themselves on the back for avoiding hiring the developer equivalent of a BOFH. Of course, this company will inevitably lay some other male employee someone off in the future for reasons that are not the employee's fault, and now they might be assumed to be "Rick". There was a small benefit to the world-at-large for them having written this, but it came with huge downsides in the manner in which they've shared.
They could have written the piece as an argument with hypothetical components strewn throughout in more of a philosophical manner including no anecdotal stories about former employees and provided the same benefits, but without the myriad of downsides. It might not have been as interesting of a read, or reached as large of an audience, but then is the conclusion they've drawn really all that mind-blowing? The story, summed up, amounts to "We spent a large amount of money on someone and after two years of continuing to spend that money, we realized that we would have been better off if we had just decided to not work on that project and had, instead, turned that money into cash and flushed it all down the toilet[0]. So we stopped spending that money. Best. Decision. Evar. /s"
[0] Because every once in a while the toilet will plug, and some of that money will come back up.
Well, kinda, but kinda not, too. When people hire builders they often know little/nothing about building a house and have a limited understanding of what quality building looks like. This company, hopefully, knew what habits a good programmer has (they must have because they eventually realized he didn't have them). Using your analogy, it'd be like a builder hiring a sub-contractor, relying on that sub-contractor to build the house in its entirety, allowing that sub-contractor to slip on the deadline by two years and when the builder went to check up on the sub-contractor, they discover the property has a kitchen, a foyer, a bunch of bedrooms but no roof or walls.
Note that I'm not saying my analogy fits perfectly, nor that "Rick" was actually the negligent builder he's been painted out to be in this but it was as much a failure on the company's side especially when you consider that they've paid this individual for those years of work knowing that it's non-refundable, they're stuck with the house, and the only option they now have is to bulldoze the property and start over. A better approach would have been to step in much earlier and correct "Rick" or get rid of him before a two-year slip in a project could occur.
This post doesn't reflect well on the outfit at all. The fact it was even published confirms the above.
It's both. Don't fall into the trap that collaboration, tenacity and mutual respect will compensate for lack of talent. You still need to find talented people, just don't hire assholes or turn them into assholes.
At least in this particular case, the combination of the red flags already mentioned by many together with the demographics of the target audience seems like a dangerous combination that promotes stigmatisation of "talents" and the idea of "if you can't become it or work with it, kill it".
I may be reading between the lines a bit too much, but the article appears to be exceedingly popular by the freeCodeCamp publication standards, and that, to me, is very unsettling for a story that I think is effectively "management turned mismanagement into a heroic triumph".
I've also worked with people genuinely like "Rick" from the article. It usually takes about a week to find out that they don't actually write any code or contribute to the team in any meaningful way besides making noise. People who are that wrapped up in their own ego cannot make meaningful contributions to their teams.
It lends more weight to the idea that there was a ton of mismanagement going on at this company that beyond the bullshit described in the article, the author still considers "Rick" to be a genius.
Richard Feynman is known to have a temper, and Einstein was known to be extremely callous in intimate affairs. We've also seen MIT professors display a lesser regard for lesser minds in math. We've also seen brilliant top-of-their field sportsman display great arrogance and disregard to lessers. The guy who writes "The Haskell Book" isn't known to be nice, but people still acknowledge that it's one of the top texts. Linus Torvalds isn't known to be nice.
You might not consider these people to be "geniuses", but they are certainly brilliant in some way, participating heavily in their field in some way.
And while one can of course say that someone is a genius at a sport, I meant specifically intellectually, and even more specifically I wanted to combat the notion that it is common for software engineers to be geniuses and total assholes. I just haven't seen that frequently, and in fact usually the pattern is that the engineers who are typical assholes are, correctly, the least secure in their own skills and try and mask that with needless complexity (in code, communication etc).
I guess maybe my meta point is that I think intelligence generally fights toxicity, not the opposite. I'm sure you can find counter examples as humans are complex.
Agreed, as I said humans are complex and I'm sure you can find exceptions. Just talking about general trends here.
> EQ and IQ are not highly correlated at all.
Assuming by EQ you mean being a nice person and intelligence are not correlated I don't agree. Tons of studies backing this up (as well as correlation with overall happiness). Here are two:
https://www.ncbi.nlm.nih.gov/pubmed/12061571
http://onlinelibrary.wiley.com/doi/10.1111/jopy.12309/full
As geniuses are already extreme outliers. For one thing, they do not typically fit in very well with their peers, often leading to seemingly anti-social behavior.
None of the articles you link directly correlate EQ to intelligence, they corrleate it to civic minded ness, and getting good grades in school. Social people do well in social environments is not surprising.
I would probably end up finding that there was none (or only a bunch of CYA paper trails), and fire everyone who was involved in that project.
EDIT: I once was recruiting for a project I was working on, and one of the candidates during a phone interview bragged about a poorly managed project they were on that "wasn't their fault". I didn't address it, but that's where they were sorely mistaken. Not doing anything when you know there's a problem (even if you don't know what the problem is) is not a valid strategy IMO.
So many red flags from the author, I'm shocked that any of their talent stayed. What a joke.
Geezus. What kind of people are running this outfit that they don't see the connection between these two phenomenon?
People who haven't spent enough time around programmers and/or people who haven't spent a serious amount of time coding themselves would be my guess.
Coding 7 days a week 12 hours a day with the entire weight of everything on your shoulders while others have "meetings" and write Medium blog posts will turn Gandi into an asshole soon enough.
Not saying the guy wasn't intrinsically a jerk but this is a ridiculous failure of management. And you are posting about this ridiculous failure in an attempt to scapegoat someone who wasn't managed for the failure of a project that was poorly managed? Shame on you author. Seriously. Grow up.
So Rick knew everything about the project, while everyone is simply making a living off his work all those months/years, saved the management face many times with miracles, probably not paid n*x, stopped attending meetings because no one understood the stuff anyway, and the author has bad opinion of Rick's code, conveniently ignoring context around Rick's choices, gleefully siding with all those managers who have no clue in the first place and fired the worker to have a new start!!!
Maybe Rick should be given a chance to comment on how bad those project savior choices were.
Now we need to wait and see when would they identify next Rick of the current version of the code when that stops cutting the muster for the flood of new requests.