5 ms·

The problem is how to determine how someone is smart. In my company we had this very eloquent, outgoing person who implemented many features very fast. To the

The problem is how to determine how someone is smart. In my company we had this very eloquent, outgoing person who implemented many features very fast. To the eyes of management he was a champ, the king of "shipping". But a little bit later things started to seem weird. Noone was productive except for this person. Only he could understand the code organization because the system wasn't well structured. Then bug reports started coming in, later on the customer complaints started coming in, and incidents were declared. The guy failed to fix the incidents and got fired. Later on, I got hired. By auditing the code base I identified multiple issues that suggested the person did not understand what he was doing. So the eloquent, passionate, cool, outgoing guy turned to be productive because he was only doing 20% of the job. All non-functional requirements were neglected. Non-functional requirements are often implicit and taken for granted. Nobody tells you "I want to not be hacked" or "I want our system to not slow down and go over capacity". Those are implicit requirements that you as an engineer need to identify, specify and implement. The non-technical leadership realized this only 2 years down the road when a huge damage was already done. So, I am going to say NO to this article. Skills are important.

nucleardog 10y ago
I got hired on at a job to replace a guy like that. He "got so much done" and "worked so hard" (was at the office late) until he up and left. Step 1 when I got hired on was to automate away half of what he was doing. I turned processes that were previously three hour projects into five minutes and a shell script. Not many late nights or 16 hour days for me. Step 2 was to finish all the work he'd left behind. It wasn't unusual to get a bug report coming in "Oh, in screen X when you try and do Y it doesn't work right." only to find that while he'd built an interface, there was no code behind any of it.
adnrw 10y ago
I think the bigger lesson is probably something along the lines of: First, make sure they can do the job technically, within some sort of parameters of what they can currently do and what can be learned on the job. That's your baseline. Then, try and suss out if they'd be good to work with. That will come naturally through the way they interact with you in the interview and how they answer questions (whether they are the questions in the article or completely different ones). If you reckon they tick the boxes for those two major attributes, it's then just a matter of weighing up how much of each attribute they bring to the table and if the balance is right.
- partycoder 10y ago
  Other scenarios are also possible. I have seen very prepared people from flagship universities that shine in interviews but have zero intention of learning and complying with industry standards and good practices and do not care about details. Those people also feel entitled to be promoted as quickly as possible, even if they're still too green to understand how software works. This is how bad engineering managers are born.
xorcist 10y ago
I have never in my life understood the word smart. Everyone is smart. No one is smart. It's a useless word, and seems overused to me (at least in American English).
- ArkyBeagle 10y ago
  You can't get people to stop sorting each other no matter what you do.
arethuza 10y ago
"But a little bit later things started to seem weird." I've met a lot of people who change jobs before anyone realises this - to anyone who works on the same projects they are a nightmare, to everyone else they look like a hotshot.
- circlefavshape 10y ago
  I have one of these on my team right now, and he has caused me more sleepless nights than anyone I have ever met. Finding it very difficult to get mgmt to understand that most of his code needs to be re-written
  - arethuza 10y ago
    This may sound paranoid, but I have seen it happen: make sure the person you are having problems with isn't sucking up to your managers and also making you look bad to them. [99% of the people I have worked with have never played those kind of political games but I have seen the utter chaos that can happen if a politically savvy operator is let loose in a trusting and politically naive environment.]
    - circlefavshape 10y ago
      Valuable advice, said individual has indeed already tried this approach with my immediate managers and my peers. Luckily I've been here long enough to have a reputation that can't easily be besmirched
    - ArkyBeagle 10y ago
      Frankly, if that works and you get fired, you didn't lose much to start with. Sorry, but keeping your job is a different skill set than doing your job. I've had to opposite experience twice - I got drop-shipped into projects where somebody had gone rogue and I cleaned it up, and then they were let go. It's most unpleasant, and had they been more perceptive they'd have known that's what was going on. In both cases, I believe they were ready to go ( and I lost any trust in the management that used this gambit and left myself shortly).
humanrebar 10y ago
> To the eyes of management he was a champ, the king of "shipping". So management also was bad at their jobs. They probably didn't get canned, though they deserved it as much as the King of Shipping. But, congratulations, you know the "What's Bad About Working Here". Maybe there's a way to train management what their implicit job responsibilities are. I've never seen it happen in the wild, but maybe it's possible.
- PaulHoule 10y ago
  That's the problem, management is bad at their jobs. Management is so bad in the U.S. that everybody imagines they can hire their way out of situations rather than manage their way out of them. For instance, when you tell people that you went to a Burger King and it took them 30 minutes to serve you a cup of coffee, the conventional answer is "it's hard to find good help these days." That's a loser attitude on the part of management. Management hires employees, fires employees, trains employees, supervises employees, etc. If management does not take responsibility for your experience as a customer it is definitely the fault of management that you have a bad experience. The problem has many facets but one of them is that few people are cut out to manage other people and our illusions about "meritocracy" contribute to an American culture that creates excellent foot soldiers but mediocre to terrible officers.
  - nommm-nommm 10y ago
    This is the reason why I find "tipping" food servers for "good service" so perverse. the quality of the service you get is almost always a function of how well the place is managed. Was your hard working server set up for failure by someone making 4 times her wage? A good manager can take a terrible team and make them a great team.
    - humanrebar 10y ago
      I usually tip well and complain to management when I get bad service for this reason. Unless business is slow and the server is obviously goofing off in the back or something.
krisdol 10y ago
Badly organized code can also be the result of demanding deadlines coupled with an inexperienced tech lead to back up the engineer's estimates. Sometimes the whole culture of a place (engineers included) is in "just get this shit done" mode until they realize they essentially need to redo everything to fox minor bugs
Cthulhu_ 10y ago
> So, I am going to say NO to this article. Skills are important. In your anecdote though, I'm reading that the er, rockstar developer had enough skills to get things done, but not the personality to do things The Right Way. That is a personality thing, I think, with personality traits like attention to detail and quality and such. Those are not linked to skill level or technology; maybe with experience (i.e. being on the receiving end of those bugs and issues), but even that is not necessary IMO, because there's plenty of smart people out there to tell people to do, for example, unit testing, and why. The wrong personality scoffs at that stuff and goes cowboy coding like the person in your anecdote.
- partycoder 10y ago
  Not really a personality thing. The person wasn't an engineer. But was given a chance because of his passion. Very much like what the article encourages.
- ArkyBeagle 10y ago
  There is nothing organically wrong with cowboy coding, especially if you're trying to find your footing with a new thing. But it's not sufficient, and probably not necessary.
pessimizer 10y ago
So this guy was working by himself, with no help, no review, and no one to discuss the implications of anything with. Sounds like a hero for managing it as long as he did.
- partycoder 10y ago
  Except that, if you are not doing well, you need to raise your hand and ask for help in the form of scope negotiation or more resources.
- sharemywin 10y ago
  good point.
ArkyBeagle 10y ago
It's always the last guy's fault. :)
collyw 10y ago
This like the last couple of applications I have inherited. Layers and layers of complexity built into the application, which could be done in a couple of database calls. It means understanding the code takes way longer than it should, and difficult to redactor, as all the extra layers add complexity and little more.
tossrblab443 10y ago
Short of more details, this sounds like organizational failure as a whole versus the failure of one developer. Was this one developer the founder or something? It doesn't make sense they got away with so much and no push back from the team? Should it be one developers job to do more than 20% of the job when it comes to shipping an entire companies products/services? It feels like you're poo-pooing the idea of a Lone Ranger coder, while being annoyed the person didn't do 100% of the work? If it's supposed to be a team effort, why should they do more than 20% of the job. The rest of the team should be contributing the other 80%. Sounds like they were there and fired before you even started. So I'm going to have to /dev/null this post as hearsay. Having a hard time understanding how this isn't downvoted to oblivion. With all the rhetoric here about quality content and posting only that which moves conversations in a constructive way, this ends up being full of holes and after the fact blame gaming. Rarely useful.
- partycoder 10y ago
  20% of the work meaning implementing only functional requirements and neglecting non-functional requirements. Error handling, monitoring, security, configuration, maintainability, unit testing, performance, scalability, etc. I think that is a personal responsibility to some extent. Even if you are doing agile or your team is small. If you don't plan to engage those requirements immediately, they need to be communicated to your stakeholders (e.g: in the form of a task in your backlog, though many of these might require refactoring/rework). Stakeholders should be aware of their completion status to make informed decisions around priorities and risk management. In an analogy, a non-functional requirement is not "adding a room to a house", it is "the construction material and construction standard to build a room". It is not something that can be added later on without rework. If they mindfully decide to accept the risks of neglecting functional requirements, it's fine, but that's their decision to make. It should not be a surprise later on that those requirements are not implemented. Then, yes, it was an organizational failure. The person was one of the first hires. But I am talking from the perspective of the article being discussed. Management put the character of the individual over skills in their hierarchy of relevance at the moment of hiring, with the results I mentioned. Then, it's not "hearsay". Evidence left: tickets, code, etc. Reading code that reflects someone not understanding CS fundamentals is not hearsay.
drinknderive 10y ago
excuse me while I humble brag and talk about myself for a second

nucleardog 10y ago

I got hired on at a job to replace a guy like that. He "got so much done" and "worked so hard" (was at the office late) until he up and left. Step 1 when I got hired on was to automate away half of what he was doing. I turned processes that were previously three hour projects into five minutes and a shell script. Not many late nights or 16 hour days for me. Step 2 was to finish all the work he'd left behind. It wasn't unusual to get a bug report coming in "Oh, in screen X when you try and do Y it doesn't work right." only to find that while he'd built an interface, there was no code behind any of it.

adnrw 10y ago

I think the bigger lesson is probably something along the lines of: First, make sure they can do the job technically, within some sort of parameters of what they can currently do and what can be learned on the job. That's your baseline. Then, try and suss out if they'd be good to work with. That will come naturally through the way they interact with you in the interview and how they answer questions (whether they are the questions in the article or completely different ones). If you reckon they tick the boxes for those two major attributes, it's then just a matter of weighing up how much of each attribute they bring to the table and if the balance is right.

partycoder 10y ago
Other scenarios are also possible. I have seen very prepared people from flagship universities that shine in interviews but have zero intention of learning and complying with industry standards and good practices and do not care about details. Those people also feel entitled to be promoted as quickly as possible, even if they're still too green to understand how software works. This is how bad engineering managers are born.

xorcist 10y ago

I have never in my life understood the word smart. Everyone is smart. No one is smart. It's a useless word, and seems overused to me (at least in American English).

ArkyBeagle 10y ago
You can't get people to stop sorting each other no matter what you do.

arethuza 10y ago

"But a little bit later things started to seem weird." I've met a lot of people who change jobs before anyone realises this - to anyone who works on the same projects they are a nightmare, to everyone else they look like a hotshot.

circlefavshape 10y ago
I have one of these on my team right now, and he has caused me more sleepless nights than anyone I have ever met. Finding it very difficult to get mgmt to understand that most of his code needs to be re-written
- arethuza 10y ago
  This may sound paranoid, but I have seen it happen: make sure the person you are having problems with isn't sucking up to your managers and also making you look bad to them. [99% of the people I have worked with have never played those kind of political games but I have seen the utter chaos that can happen if a politically savvy operator is let loose in a trusting and politically naive environment.]
  - circlefavshape 10y ago
    Valuable advice, said individual has indeed already tried this approach with my immediate managers and my peers. Luckily I've been here long enough to have a reputation that can't easily be besmirched
  - ArkyBeagle 10y ago
    Frankly, if that works and you get fired, you didn't lose much to start with. Sorry, but keeping your job is a different skill set than doing your job. I've had to opposite experience twice - I got drop-shipped into projects where somebody had gone rogue and I cleaned it up, and then they were let go. It's most unpleasant, and had they been more perceptive they'd have known that's what was going on. In both cases, I believe they were ready to go ( and I lost any trust in the management that used this gambit and left myself shortly).

humanrebar 10y ago

> To the eyes of management he was a champ, the king of "shipping". So management also was bad at their jobs. They probably didn't get canned, though they deserved it as much as the King of Shipping. But, congratulations, you know the "What's Bad About Working Here". Maybe there's a way to train management what their implicit job responsibilities are. I've never seen it happen in the wild, but maybe it's possible.

PaulHoule 10y ago
That's the problem, management is bad at their jobs. Management is so bad in the U.S. that everybody imagines they can hire their way out of situations rather than manage their way out of them. For instance, when you tell people that you went to a Burger King and it took them 30 minutes to serve you a cup of coffee, the conventional answer is "it's hard to find good help these days." That's a loser attitude on the part of management. Management hires employees, fires employees, trains employees, supervises employees, etc. If management does not take responsibility for your experience as a customer it is definitely the fault of management that you have a bad experience. The problem has many facets but one of them is that few people are cut out to manage other people and our illusions about "meritocracy" contribute to an American culture that creates excellent foot soldiers but mediocre to terrible officers.
- nommm-nommm 10y ago
  This is the reason why I find "tipping" food servers for "good service" so perverse. the quality of the service you get is almost always a function of how well the place is managed. Was your hard working server set up for failure by someone making 4 times her wage? A good manager can take a terrible team and make them a great team.
  - humanrebar 10y ago
    I usually tip well and complain to management when I get bad service for this reason. Unless business is slow and the server is obviously goofing off in the back or something.

krisdol 10y ago

Badly organized code can also be the result of demanding deadlines coupled with an inexperienced tech lead to back up the engineer's estimates. Sometimes the whole culture of a place (engineers included) is in "just get this shit done" mode until they realize they essentially need to redo everything to fox minor bugs

Cthulhu_ 10y ago

> So, I am going to say NO to this article. Skills are important. In your anecdote though, I'm reading that the er, rockstar developer had enough skills to get things done, but not the personality to do things The Right Way. That is a personality thing, I think, with personality traits like attention to detail and quality and such. Those are not linked to skill level or technology; maybe with experience (i.e. being on the receiving end of those bugs and issues), but even that is not necessary IMO, because there's plenty of smart people out there to tell people to do, for example, unit testing, and why. The wrong personality scoffs at that stuff and goes cowboy coding like the person in your anecdote.

partycoder 10y ago
Not really a personality thing. The person wasn't an engineer. But was given a chance because of his passion. Very much like what the article encourages.
ArkyBeagle 10y ago
There is nothing organically wrong with cowboy coding, especially if you're trying to find your footing with a new thing. But it's not sufficient, and probably not necessary.

pessimizer 10y ago

So this guy was working by himself, with no help, no review, and no one to discuss the implications of anything with. Sounds like a hero for managing it as long as he did.

partycoder 10y ago
Except that, if you are not doing well, you need to raise your hand and ask for help in the form of scope negotiation or more resources.
sharemywin 10y ago
good point.

ArkyBeagle 10y ago

It's always the last guy's fault. :)

collyw 10y ago

This like the last couple of applications I have inherited. Layers and layers of complexity built into the application, which could be done in a couple of database calls. It means understanding the code takes way longer than it should, and difficult to redactor, as all the extra layers add complexity and little more.

tossrblab443 10y ago

Short of more details, this sounds like organizational failure as a whole versus the failure of one developer. Was this one developer the founder or something? It doesn't make sense they got away with so much and no push back from the team? Should it be one developers job to do more than 20% of the job when it comes to shipping an entire companies products/services? It feels like you're poo-pooing the idea of a Lone Ranger coder, while being annoyed the person didn't do 100% of the work? If it's supposed to be a team effort, why should they do more than 20% of the job. The rest of the team should be contributing the other 80%. Sounds like they were there and fired before you even started. So I'm going to have to /dev/null this post as hearsay. Having a hard time understanding how this isn't downvoted to oblivion. With all the rhetoric here about quality content and posting only that which moves conversations in a constructive way, this ends up being full of holes and after the fact blame gaming. Rarely useful.

partycoder 10y ago
20% of the work meaning implementing only functional requirements and neglecting non-functional requirements. Error handling, monitoring, security, configuration, maintainability, unit testing, performance, scalability, etc. I think that is a personal responsibility to some extent. Even if you are doing agile or your team is small. If you don't plan to engage those requirements immediately, they need to be communicated to your stakeholders (e.g: in the form of a task in your backlog, though many of these might require refactoring/rework). Stakeholders should be aware of their completion status to make informed decisions around priorities and risk management. In an analogy, a non-functional requirement is not "adding a room to a house", it is "the construction material and construction standard to build a room". It is not something that can be added later on without rework. If they mindfully decide to accept the risks of neglecting functional requirements, it's fine, but that's their decision to make. It should not be a surprise later on that those requirements are not implemented. Then, yes, it was an organizational failure. The person was one of the first hires. But I am talking from the perspective of the article being discussed. Management put the character of the individual over skills in their hierarchy of relevance at the moment of hiring, with the results I mentioned. Then, it's not "hearsay". Evidence left: tickets, code, etc. Reading code that reflects someone not understanding CS fundamentals is not hearsay.

drinknderive 10y ago

excuse me while I humble brag and talk about myself for a second