5 ms·
Here is yet another person who doesn't understand that he is first and foremost hired to solve business problems, not to write software. It so happens that he w
by johnloeber 10y ago
Here is yet another person who doesn't understand that he is first and foremost hired to solve business problems, not to write software. It so happens that he writes software to solve these problems.
If it turns out that he actually creates further business problems (and by the content of the post, it certainly looks like it), then no matter how "elegant" or "brilliant" his code is, it's rational to let him go!
- spinningarrow 10y agoWhat further business problems is he creating?
- AimHere 10y agoSoftware that's not maintainable by his coworkers.
- i_feel_great 10y agoIs quality Typescript/Node.js code, which is "intelligently decoupled", harder to maintain than poorer quality code?
- dogma1138 10y agoIf it's so far from the normal coding standard and practices within the company it doesn't matter if it's better or worse it's just as unmaintainable.
- deleted 10y ago[deleted]
- Tiquor 10y agoIntelligently decoupled, no. Needlessly abstract, yes. Many rockstars can't tell the difference.
- pjc50 10y agoSoftware is, among other things, a form of communication between humans. That's what Knuth's "literate programming" ideas aimed towards. It's also a driver of lots of these methodologies he's so fond of: we use them because they are easier to understand than the wordier alternatives. Whatever else his code is (and remember, we only have his opinion that it's good, we can't judge for ourselves), he's failing really badly to communicate with his co-workers and bosses.
- dogma1138 10y agoIf no one in the team can understand or maintain his code it doesn't matter if it's because it's way above or below the coding standards of the company. A company can't afford to pretty much be dependable on a single person, what happens if they get sick or decide to leave? Being a star employee is good, but it always comes with the risk, people think that being indispensable is good, it might be good in a small startup but not in a large company. At the end regardless how good they are they are only a small part of the delivery bandwidth of the company, and regardless of how good they are they can't do the job of 10 people even if they are smarter than 10 people combined. As a developer their job is to produce reliable and maintainable code, this means that the code can be picked up by anyone in the company and worked with, if they don't they effectively create a bottleneck and a dependency on a human resource which is a huge risk for any business. It's ok to be good, it's ok to even be better than some, or even the rest as long as you are a notch above the rest primarily due to soft skills, if the product you produce is effectively alien to the rest of your team and the company then what you produce is a liability not a solution.
- cmdkeen 10y agoFrom the way I read it he is a contractor hired for a specific project - in which case there is an expectation that he will leave at some point. There's also a couple of serious red flags in describing a contract as "In my contract, I had to work ALONE in order to build a complete software alone, with my own programming principles. I was recruited BECAUSE the team has no skills at all in the demanding fields." Which means there's no use of code reviews, even as an opportunity to educate someone else. There appears to be no process for knowledge transfer at all, so how is the company going to gain these skills? Separate principles again suggests not writing code in the same way as everyone else. Plus if you're concerned after 2 previous incidents of this happening to you and you find yourself months into a project being left on your own then some pre-emption might be useful. Write lots of comments in your code, talk colleagues through it, suggest training videos on the languages technology - make yourself useful and available.
- dogma1138 10y agoI'm not saying that this was handled well from either side, but as a contractor you are hired to deliver a product to a company; if that product is effectively useless once you are done with your product you have not delivered what you were contracted to do. A contractor that would produce some fully functional, and even elegant in it's own way but convoluted piece of code is doing a poor job regardless if it's because the code is so smart that almost no one can understand it or because it's utterly inconsistent internally and is an unreadable mess. You aren't selling a binary product here, a company isn't buying off the shelf software, they are contracting you to further develop their IP if what you produce is not useable to them you effectively wasted their time and money.