Live data from Hacker News

Beware of Developers Who Do Negative Work

blog.professorbeekums.com

181–190 of 271 posts

Re: Beware of Developers Who Do Negative Work

#181

> So if the cost of a developer who does negative work is so high, how do they get hired? Part of it can be explained by an interview process that needs improvement, but a less talked about part is the temptation to lower hiring standards. I've seen plenty of people who can reverse binary trees or fizzbang etc who are terrible additions to teams and do "negative work". That's because having a grasp of CS fundamentals…

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…

Junior people who are very good at CS often struggle with "real-world software".

I had to explain to such a developer once why it was a bad idea to store multiple values into a single database column.

It was a simple task of adding a few integer columns to a table but he couldn't let go of the "optimizations" in his mind about how he could use binary bits to represent what we wanted to represent and all that...

A person with good CS fundamentals need to go through some tough times for a few years at dev shops where the rubber meets the road and then they'll develop a technical taste.

Re: Beware of Developers Who Do Negative Work

#182

While the concept of negative work is certainly instructive, my misgiving is that it's probably difficult or impossible to measure the overall value added (or subtracted) by any worker in a complex organization. My guess is that most of us have our positive and negative moments, and hopefully the positives outweigh the negatives.

Great point. While articles would have you believe that programmer skill is bimodally distributed (good vs. bad), it actually follows a normal curve like most other things. We all make some good decisions and some bad decisions everyday.

I'm sure we can all find a piece of code we wrote a year or two ago that makes us cringe a little bit.

Re: Beware of Developers Who Do Negative Work

#183
As an entrepreneur and former manager and engineer I find this analysis too simplistic.

In particular he talks about outdated methods making work negative and while I agree, most of the time I find the opposite problem: most programmers wanting to use the new language of the Week.

The new language of the Week was so great and saved so much time on some area but because it is not production ready you are forced to fill the gaps and do a ton of work that would never be necessary with the mature language in other areas, like installing libraries and dependencies, resolving conflicts that nobody had solved before because so few people use the new language...or just debugging the new language itself.

Also as a manager it is your job and responsibility to make things work. If you can't see the problems before they happen and manage it it is your fault, not the developer's.

People have a lot of psychological delusions and faults, but as a manager you study them and if you are good could handle it easily. If a soccer team is not well organized is not the responsibility of the players.

If a person has a tendency to use outdated software like the player wanting to dribble to much, you correct it and basically everybody is happy. When things go good and you have success everybody is happy.

Re: Beware of Developers Who Do Negative Work

#184
post #157

Earlier quoted context omitted.

> I'm also involved in an education program for children and as a matter of fact computer science is among the most difficult subjects to teach, right up there with math. Yes, you can increase interest and engagement by better teaching methods (e.g. playing and building games), but that CS is hard is indisputable. I'll dispute it. I did a year of a split maths/computer science degree, found the computer science easy,…

As I happen to know which course you're talking about, I would point out that the module of CS you took was the far easier half of the first year material, which was open to people from a variety of other subjects, and designed with that in mind. (And indeed, the Maths dept recognises this and doesn't reduce the workload to compensate for Maths students who choose it.) While I wouldn't say the rest of the course push…

> As I happen to know which course you're talking about, I would point out that the module of CS you took was the far easier half of the first year material, which was open to people from a variety of other subjects, and designed with that in mind. (And indeed, the Maths dept recognises this and doesn't reduce the workload to compensate for Maths students who choose it.)

I did everything other than the hardware module (digital electronics) AIUI? (Which was maybe the hardest part for some people, but doesn't really correspond to the kind of thing that's asked in interviews).

Re: Beware of Developers Who Do Negative Work

#185

Considering 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…

I have dealt with the "negative work" conundrum myself and just wanted to give some insight from my point of view on your comment.

1) It isn't always junior level programmers causing the negative work. When it is a junior level programmer, you are 100% correct that part of the blame (or MOST of the blame) falls on the lead/senior programmer. The lead/senior failed the junior without the appropriate structure, code review, etc to make their code maintainable and "healthy". Happened to me just this year and I let down one of the junior engineers on the team in a massive way and it showed.

2) What happens in the scenario that a senior/lead person is the one creating the negative work? Adding more oversight/tighter feedback loops constrains this person and will make them worse off than not. Anyone can make the argument that this person should not be a lead or a senior, but due to any number of business alterations (organizational changes, leadership changes, culture changes, etc) it is 100% a plausible scenario. What do you do then? How do you manage this piece of the puzzle?

Scenario 2 is where I have seen the most "negative work" created without finding optimal paths for fixing the issues at hand.

Re: Beware of Developers Who Do Negative Work

#186
post #44

Earlier quoted context omitted.

This is definitely true on both ends. At a previous company, the tech influencers believed in the archaic "do everything in the database." While we were technically using the .Net stack, we weren't allowed to do any actual business logic in C#. Instead it had to all be done in MS-SQL procedures (or at least at much as possible with very little CLR glue). Similarly at my current company, we had a product were the init…

> At a previous company, the tech influencers believed in the archaic "do everything in the database." While we were technically using the .Net stack, we weren't allowed to do any actual business logic in C#. There's nothing archaic about that, actually. It ensures that your domain logic remains DRY and is not repeated for every new application or service that you connect to your data.

Valid point. Sadly, the system I was working on at said company was monolithic, so I don't believe that advantage was being utilized. It does open it up the potential in the future though.

I feel that this could be solved in other ways as well. Such as with microservices to wrap your database and provide endpoints for other services to consume. This is more like how we do it at my current company.

Re: Beware of Developers Who Do Negative Work

#187
post #44

Earlier quoted context omitted.

This is definitely true on both ends. At a previous company, the tech influencers believed in the archaic "do everything in the database." While we were technically using the .Net stack, we weren't allowed to do any actual business logic in C#. Instead it had to all be done in MS-SQL procedures (or at least at much as possible with very little CLR glue). Similarly at my current company, we had a product were the init…

> At a previous company, the tech influencers believed in the archaic "do everything in the database." While we were technically using the .Net stack, we weren't allowed to do any actual business logic in C#. There's nothing archaic about that, actually. It ensures that your domain logic remains DRY and is not repeated for every new application or service that you connect to your data.

I guess it depends on your application. To me having multiple applications accessing the same database logic (or domain) feels very archaic, or at least hard to maintain.

You'll end up with highly coupled application(s) and a schema that is very hard to change and nearly impossible to deploy small changes in continuous deployment scenario's without maintenance windows. In my experience it's hard to maintain high performance and 0 deployment downtime in applications only using SQL databases multiple applications sharing tables/views.

Then there's always additional platforms for specific areas that are just way more hard in a relational database such as journaling (append only data), queuing, (distributed) caching and searching that will scatter your logic outside the database anyway.

I've found it really hard maintaining DRY principles, finding a balance between readability and performance in large SQL based applications without an extremely disciplined team.

Re: Beware of Developers Who Do Negative Work

#188
post #56

The "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…

Are you suggesting that all functional code is readable/more readable? It has its merits for sure, but I have seen many functional monstrosities... some that have even caused plenty of negative work themselves!

What I am suggesting is that the majority of people at a company will decide what styles of programming are "convoluted." According to the article the programmers who write convoluted code are the ones having a negative impact. The double edged sword is the allegory of Plato's Cave: you might actually be bringing the team great ideas about how to improve their code but it will be useless if they can't see the shadows on the wall for what they are.

While I may be biased and find that functional programming styles are better I realize it takes all kinds to make a working system together with other engineers. The difficulty is in communicating these ideas and pulling the team together to see the merit rather than the shadows.

Re: Beware of Developers Who Do Negative Work

#189
post #184

Earlier quoted context omitted.

As I happen to know which course you're talking about, I would point out that the module of CS you took was the far easier half of the first year material, which was open to people from a variety of other subjects, and designed with that in mind. (And indeed, the Maths dept recognises this and doesn't reduce the workload to compensate for Maths students who choose it.) While I wouldn't say the rest of the course push…

> As I happen to know which course you're talking about, I would point out that the module of CS you took was the far easier half of the first year material, which was open to people from a variety of other subjects, and designed with that in mind. (And indeed, the Maths dept recognises this and doesn't reduce the workload to compensate for Maths students who choose it.) I did everything other than the hardware modul…

My understanding is that your course sits one of the two CS Papers? They tend to move modules around a lot, but based on a quick look through past years' material, I'm fairly sure Paper 2 would have covered significantly more than Digital Electronics in your year.

Re: Beware of Developers Who Do Negative Work

#190
TL;DR: Some devs introduce toxic code in your codebase, you shouldn't hire them.

However, it seems to me proper code reviews and mentoring would have prevented that in the first place? That's an important responsibility for the 'good' devs, and you can't simply complain after the fact if you aren't proactive in that sense.

Post reply on HN