Live data from Hacker News

Beware of Developers Who Do Negative Work

blog.professorbeekums.com

141–150 of 271 posts

Re: Beware of Developers Who Do Negative Work

#141

Good points. Regarding how such people come to influence, you have to remember a lot of people, especially in startups, are not hired through a process at all. I worked with a guy for many years who was as described in this article. He can't code and he can't do any math, despite holding a phd. He can talk about math and he can talk about code, but we're talking excel level skills when what you need is someone with a…

> First of all, the boss of the fund did not have the skills to judge who could write a trading strategy, and who couldn't.

The Dunning–Kruger effect in action.

Re: Beware of Developers Who Do Negative Work

#142

An even more egregious form of negative work is a developer who is stuck using out of date programming practices AND has a large amount of influence at a company. At the other extreme is the developer who is so entranced by "newer is better" mentality that they rewrite everything in an attempt to conform to "latest best practices", increasing complexity massively while introducing a bunch of bugs and huge dependencie…

I think rewriting code for style purposes extremely naive. It introduces risk and sabotages `git blame`. Still see a lot of time wasted doing exactly that, as enthusiastic developers try to illuminate the rest of the team, or make things tidy. I recommend against switching to something like "standard.js" in a live project.

Agreed. There should be a standard way that everybody on the team formats their code on check-in, and that format should not change. That way, it can be enforced by a single git pre-commit hook to clang-format. If somebody wants to work on the code formatted in a different way, well then that's just more calls to clang-format, but it never touches the repository that way.

Re: Beware of Developers Who Do Negative Work

#143

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…

It's hilarious, because our best hires are people who had no CS education. Meanwhile, some of the worst hires were CS grads. Things that are hard to teach: Can you work in a team, especially if some of them are remote workers? Can you leave your ego behind? Can you deal with the corporate BS that gets in the way of programming? Can you think of the user, use-cases, business value, etc of the feature/product you're de…

That CS fundamentals and programming are easy to teach is a myth that keeps being perpetuated and I don't understand why.

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.

> Can you work in a team, especially if some of them are remote workers? Can you leave your ego behind?

In our line of work, working as an individual on your own piece is actually what happens in 90% of cases. The other 10% you have to cooperate with your team to make decisions and to reach compromises on points of intersection, on protocols, on best practices, etc.

But if we are honest with ourselves, collaboration in our industry means having contention / concurrency in the development process and that doesn't scale and minimizing contention leads to better productivity. This is why we hate open spaces, why we ended up with micro-services, or why we split big teams in smaller teams. It's all about achieving parallelism by reducing the needed collaboration.

Don't take offense in me saying this, but team work is a soft skill that isn't hard to teach or learn at all. So lets be blunt. You're talking about assholes and having assholes really depends on your company's culture and what gets tolerated. If you don't tolerate assholes, some people will change their attitude, some will leave and the rare few will have to be fired, but such cases are rare.

Re: Beware of Developers Who Do Negative Work

#144

Earlier quoted context omitted.

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

That's a valid point of course, thanks for pointing this out! I assumed that the organization in which you work is at least partially functional and that management has an interest in ensuring good working conditions, which as you say is not always the case. 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…

I agree. Funny story with the code review, we had that. But several devs kept submitting broken/bad code, so they could tell their manager "oh, I'm waiting on a code review". The loss of productivity due to other devs trying to do constructive code reviews was staggering.

One guy was asked to leave a project after he submitted 17 updates to the same commit, and all of them failed basic (and luckily automated) linting. Another contractor titled all his commit messages a single word: "update". I've even worked on a project where the build system was "maintained" by contractors - talk about a conflict of interest. You can imagine how transparent it was.

Re: Beware of Developers Who Do Negative Work

#145

Earlier quoted context omitted.

It was my job for a while to work with scientists and their spaghetti Fortran codebases. One esteemed fellow still stuck to the FORTRAN IV of his youth (the original pasta language). It was amazing how much they could do with such old technology. The overriding impression ultimately was: "Never keep intellectual property just in code"

I feel your pain. Scientists & data scientists are notorious for spaghetti code. Refactoring scientists code was how I got into software engineering. I used to be a scientist, and I found restructuring/modularizing the analysis code more fulfilling than the actual analysis.

As someone who is currently in that exact situation, and is considering switching away from science, how did the actual switch from science to software go?

Re: Beware of Developers Who Do Negative Work

#146

Earlier quoted context omitted.

It's hilarious, because our best hires are people who had no CS education. Meanwhile, some of the worst hires were CS grads. Things that are hard to teach: Can you work in a team, especially if some of them are remote workers? Can you leave your ego behind? Can you deal with the corporate BS that gets in the way of programming? Can you think of the user, use-cases, business value, etc of the feature/product you're de…

That CS fundamentals and programming are easy to teach is a myth that keeps being perpetuated and I don't understand why. 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 i…

* Big-O. It's basically enough to know when an algo is going to perform horribly - e.g. O(n^3) - and even then you might choose it because it's simple or your n is currently small. Anyway, senior dev or architect can make this call way better than any grad could, CS or not.

* Data structures. Many high-level languages now have better basic data-structures than many devs could write, even if they know the theory.

I could continue, but most people do fine without these CS 101 basics. Besides, good/interested people will ask questions about the code base and will read up on these concepts when mentioned. Doesn't take a genius.

> but team work is a soft skill that isn't hard to teach or learn at all

Let me get this straight. You're saying that behaviours you might have established in your teens, and so held unconsciously for almost 10 years by the end of your degree, those are easier to change than something you just learned? Something that people can teach themselves as a hobby, and often do?

But, if soft skills are really that easy to teach, I have several, lucrative opportunities for you. Meanwhile, CS courses online are a dollar a dozen or free. Honestly, if you could write up some stuff about this, I'm sure several people on HN would appreciate truly actionable advice on how not to accidentally be an asshole. Even better, if you can somehow make great devs into great managers, that's also worth gold.

I will admit that good teachers really help with both maths and CS, and good teachers are rare. Luckily, I had a good mentor by accident when I was 14. This year, our team has been to twelve local schools to help teachers make it more fun. And yeah, some kids struggle, just like any subject, but most actually have no issue at all picking this stuff up. Not worried in the slightest about the next generation's programming skills.

Re: Beware of Developers Who Do Negative Work

#147

Good points. Regarding how such people come to influence, you have to remember a lot of people, especially in startups, are not hired through a process at all. I worked with a guy for many years who was as described in this article. He can't code and he can't do any math, despite holding a phd. He can talk about math and he can talk about code, but we're talking excel level skills when what you need is someone with a…

I work in finance and I've seen the same thing happen. I guess it's more common than people realise.

[deleted]

Re: Beware of Developers Who Do Negative Work

#148

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…

You are right but I also can understand his 'influential developer' negativity effect. In my place there's this one influential developer (the Team Lead) that can veto every decisions even though the others juniors/seniors under him already have consensus. He doesn't want the existing process to be altered. Now he's alone as everyone is leaving.

Re: Beware of Developers Who Do Negative Work

#150

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…

I find a lot of CS education is not applicable to most SE roles, as they operate at a higher level of abstraction. I've never had to implement a binary tree, if I did, I would be reinventing the wheel. A lot of the necessary skills are hard, if not impossible, to teach in higher education. Mainly because there, you tend to be given an exact, unambiguous specification. Whereas in the commercial world, I've never seen…

> Implementing the code is the easy bit :)

For web forms that replace an Excel spreadsheet, the kind that usually gets passed around over email or in a Dropbox, yes, the business requirements are usually the ones that are problematic, as you are expected to grok a lot of domain specific details in only a couple of days.

But then again IMO, your experience is biased by the problems you've been working on.

> I've never had to implement a binary tree, if I did, I would be reinventing the wheel.

If you actually had problems involving trees, you'd know that besides the usual data-structures we all know and love, problems involving trees and graphs rarely have prepackaged solutions and the available solutions are leaky abstractions for which you have to know how they work in order to fine tune them or to make a choice between the available solutions. Consider that problems involving graphs many times involve NP solutions that are unacceptable, but that admit solutions producing approximate results, which may or may not be acceptable for your problem.

And sure, maybe the problems that you're solving don't involve trees or graphs. That's fine, I think it's been 2 years since I saw a graph problem myself, but then again, medics learn a lot more than they need to treat the common cold, in order for them to be prepared. I wouldn't want to be treated by a doctor that doesn't have the proper education, since my life is on the line. And yet we are the industry that accepts people without a college degree, but given that we also have a lot of responsibility on our shoulders, how accepting can we get? Consider that we build software that controls buildings, that drive cars, that process the confidential data of people.

And we as software developers, when we meet, what are we going to talk about anyway? Sure, you might have some personal projects we can talk about, but lets circle back to beginners. What are you going to talk about with somebody fresh out of college or high-school? And even with seniors, not everybody has an interesting project to talk about, so how are you going to assess their worth? Sure, you can always do a trial, but the reality is that firing people is hard and expensive, that's just the way things are and most companies prefer false negatives.

Post reply on HN