Earlier quoted context omitted.
Even though CS fundamentals and contributing in teams are somewhat different skills, in my experience the terrible developers that contribute negatively to the project tend to be those that do not have a good grasp of CS fundamentals. I mean, some problems we are faced with are very, very challenging and if somebody can't figure out how to reverse a binary tree or do a FizzBuzz, then what can he do? Also I'm hearing…
Also if you restrict hiring to recommendations it's going to be even worse for your diversity. We can at least try to have a recruitment system that doesn't place too much weight on what people's faces look like or nebulous "cultural fit".
Beware of Developers Who Do Negative Work
131–140 of 271 posts
Re: Beware of Developers Who Do Negative Work
#132Earlier quoted context omitted.
All of that apart from 5 is totaly wrong
Care to elaborate a bit? Especially, why do you think unit testing and debugging of SQL is not hard?
An SQL returns results directly in tables which you can check in all kinds of ways. You can create any number of temporary tables, with the same schema as your business tables, and check all kinds of invariants.
There's absolutely no reason why unit testing SQL should be harder than anything else, considering a single query as the "unit" of testing.
In fact, that's to the built-in checks, constraints and types a RDBMS has, you are freed from having to unit test all kinds of crap too (similar to having less to unit test in Haskell vs Ruby).
Re: Beware of Developers Who Do Negative Work
#133The "convoluted code" gauge is a double-edged sword. You could also be working at a company with developers who have no experience with the benefits of functional programming. In this scenario it's those who write nested loops, branching if-statements, and mutating side-effects that are in charge and you're the bad developer for using fold and map. You could be seen as an elitist who likes to write clever, obfuscated…
Functional programming does have some useful syntax and principles that can make code easier to reason about. But a much bigger red flag is if a developer is so fixated on a certain programming philosophy or methodology that they don't pay attention to writing simple, good code.
Re: Beware of Developers Who Do Negative Work
#134Earlier quoted context omitted.
All of that apart from 5 is totaly wrong
What's the solution for source controlled database logic?
Have your statements (including those that create stored procedures on setup, migrations, etc) on text files, and just load those into your Git or whatever.
Re: Beware of Developers Who Do Negative Work
#135Earlier quoted context omitted.
All of that apart from 5 is totaly wrong
What's the solution for source controlled database logic?
Re: Beware of Developers Who Do Negative Work
#136Re: Beware of Developers Who Do Negative Work
#137Considering that the author writes on his resume that he lead several teams, it startles me a bit to see how easily he puts all the blame on the developer and none on the other team members (including him) and the management. The way I see it, as a senior developer or team lead it is your job to make sure that your junior level programmers are doing good work, and if they don't, you either help them to improve or (if…
This article reeks of bullying, passing the buck and misplaced egos, imo. The solution provided is focused on how to avoid hiring 'problem' employees, unfortunately nothing about how to cope with the situation once it has arisen. People can change after the hiring process due to personal reasons, death, divorce, all sorts of things. The author's company does not sound like a good place to work staffed with nice people.
Re: Beware of Developers Who Do Negative Work
#138I would fault this article for treating each developer as a being intrinsically good or bad. I've seen people I know are very talented (based on past work) become negative developers. Depression is a common cause. If they are underperforming they may react to their own self-disappointment by acting defensive and resisting change of the inclusion of anyone they think may judge them. I think there's many destructive fe…
So that's another layer of variation to take into account.
Re: Beware of Developers Who Do Negative Work
#139Considering that the author writes on his resume that he lead several teams, it startles me a bit to see how easily he puts all the blame on the developer and none on the other team members (including him) and the management. The way I see it, as a senior developer or team lead it is your job to make sure that your junior level programmers are doing good work, and if they don't, you either help them to improve or (if…
> let them go Erm, that isn't how corporations work. First, team lead doesn't mean manager, and even then in some companies, first and second line have very little to say. HR needs to be involved, etc. Which creates more work. There are the people who simply don't care. Contractors on a gravy train or outsourced people. I've been there, there is nothing you can do in this case. I think it's fair to say from your resu…
But even if you're not in a position to do hiring/firing decisions there is still a lot you can do to make it harder for other people to do bad work. One of the easiest things is to agree on a standard for your codebase with the other developers, and create a process through which you monitor this standard (e.g. through code reviews).
If that's not possible due to resistance from management or a dysfunctional organization, you should consider leaving that position as soon as possible as it is not a good environment to work in (and as the author says, luckily there are enough opportunities for good programmers these days). But again, the problem here would not be the single bad programmer, but the setup of the whole organization, which is unfortunately much harder to fix.
Re: Beware of Developers Who Do Negative Work
#140It's true that not all developers make positive contributions, however, I think that blaming "lowering hiring standards", as the author said, is a complete red herring. There is such thing as hiring without doing even the most basic test for technical competency: Last year, at a different job, I worked with a guy that though the best way to implement a CRUD service was an nginx plugin, and when faced with a real prog…
I've seen it done, far too often. Management-only hiring interviews because devs were being "too stringent" and it was "time-sensitive". A guy who had "contributed to the Linux kernel", but his FizzBuzz implementation didn't work. Of course, management didn't notice, only by luck did a dev look at the whiteboard after the interview.
Or, even if they haven't lowered, someone slips through the cracks. They then usually bounce from team to team, happily collecting paychecks. Then, after they've been around for years, having worked on so many projects, management considers them senior somehow. Everybody thinks "can't be that bad if nobody has fired him", and thus firing never occurs.