Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

How to Make Other Developers Hate to Work with You

anaxi.com

Post reply on HN
Print view View original

111–120 of 191 posts

Re: How to Make Other Developers Hate to Work with You

#111

Post by rabidrat »

vidanay wrote: post #81
koboll wrote: post #49

Holy crap, is >gives cryptic names for variables, or at best not self-explanatory sure a big one. It's part of a category of small decisions that dramatically increase cognitive load when accumulated. Along with it: >Passing many arguments into functions with names that have no relevance to their role inside the function, so you constantly have to look up which argument maps to which function param >Needlessly reorga…

A former primary developer of my code base had something wired backwards in his brain. The code is full of double negatives: if(!FeatureNotDisabled){ .... } It drives me absolutely bonkers!

For me this often happens incrementally. Like they started with "if (FeatureNotDisabled)" and then locally refactored the code until it was "if (!FeatureNotDisabled)". The problem is that they then didn't go back for another pass before commit, and reverse the double-negative by changing the variable name and semantics. This could be due to laziness, ignorance (it works, what's the problem?), fear (it works now, let's not break it), or time mismanagement (it took long enough to get it working, no time to make everything "perfect").

Re: How to Make Other Developers Hate to Work with You

#112

Post by ianstallings »

Dzugaru wrote: post #65

> Developers can’t easily go back to where they were right > before an interruption. They need to get into the mindset > for development and then slowly trace back to where they > left off. And every fellow developer knows that. I used to think like that too, but after 10 years programming in many environments, now I'm inclined to disagree. If I cannot refocus immediately after interruption - I know I'm doing somethi…

One of the things I do to offset possible interruptions is to write things out or visualize them in some way. It helps me pick back up on the track I was interrupted from, but also has the added benefit of helping visualize the problem, which often leads to a greater understanding. It's a little bit of overhead that can pay off.

Re: How to Make Other Developers Hate to Work with You

#113

Post by lolc »

Dzugaru wrote: post #65

> Developers can’t easily go back to where they were right > before an interruption. They need to get into the mindset > for development and then slowly trace back to where they > left off. And every fellow developer knows that. I used to think like that too, but after 10 years programming in many environments, now I'm inclined to disagree. If I cannot refocus immediately after interruption - I know I'm doing somethi…

To me that just sounds like you don't have tasks that require deep thought. And that you've developed habits to cope with interruptions, such as note-taking.

To turn a complex thing into a list of simple things can be done by experience as well as by deep thought. But don't think you could get that experience in 5-minute chunks of thinking. To get the experience you need deep thought.

Maybe set your sights higher if it's all easy to you? Or enjoy the fruits of experience, of course.

Re: How to Make Other Developers Hate to Work with You

#114

Post by gerbilly »

zimablue wrote: post #73
RyanDagg wrote: post #57

Earlier quoted context omitted.

I just read the article and was like “I don’t think I suffer from these much at all” then read this comment. This is very insightful and also something I just realized that I greatly suffer from. Thanks.

I relate to this. I think one of the symptoms is not picking up enough detailed understanding of anything because you keep moving around and don't believe in most external knowledge anyway (eg. don't want to learn [beyond a certain depth] SQL, it's so ugly on some inner level I'd much rather start with datalog and build my own up, don't want to learn economics I don't trust those science cargo-culters). But the other…

> SQL, it's so ugly on some inner level I'd much rather start with datalog and build my own up

SQL syntax may be ugly, but for once, it's an example of a widely used technology that is based on a very firm and well thought out theoretical framework.

As a developer, it is definitely worth investing time in understanding relational databases and the theory behind them.

https://en.wikipedia.org/wiki/Relational_calculus

Re: How to Make Other Developers Hate to Work with You

#115

Post by timw4mail »

vidanay wrote: post #81
koboll wrote: post #49

Holy crap, is >gives cryptic names for variables, or at best not self-explanatory sure a big one. It's part of a category of small decisions that dramatically increase cognitive load when accumulated. Along with it: >Passing many arguments into functions with names that have no relevance to their role inside the function, so you constantly have to look up which argument maps to which function param >Needlessly reorga…

A former primary developer of my code base had something wired backwards in his brain. The code is full of double negatives: if(!FeatureNotDisabled){ .... } It drives me absolutely bonkers!

That's a triple negative! (!, Not, Disabled).

Yes, `if (!FeatureEnabled){ ... }` would be clearer.

Re: How to Make Other Developers Hate to Work with You

#116

Post by [deleted] »

ltbarcly3 wrote: post #40
vharuck wrote: post #18

I thunk there's a second "flavor" of arrogance, where a person believes they're the smartest, but not most knowledgeable, in the room. These people will openly admit they can improve and seek training, partly because they believe they're capable of anything. They don't think they're at the top of the mountain, just that their mountain has no peak. The real problem is they believe "lazy" coworkers will eventually be b…

Arrogance has very little to do with thinking you know a lot, or disagreeing with others, and everything to do with failing to follow social protocol. If you let other people speak, pause long enough that they feel like you are giving their words a fair evaluation, and then don't use words that they must interpret as telling them they are wrong you will not be seen as arrogant. This is true even if you rarely or neve…

[deleted]

Re: How to Make Other Developers Hate to Work with You

#117

Post by dragonwriter »

timw4mail wrote: post #115
vidanay wrote: post #81

Earlier quoted context omitted.

A former primary developer of my code base had something wired backwards in his brain. The code is full of double negatives: if(!FeatureNotDisabled){ .... } It drives me absolutely bonkers!

That's a triple negative! (!, Not, Disabled). Yes, `if (!FeatureEnabled){ ... }` would be clearer.

> That's a triple negative! (!, Not, Disabled).

It's only a double negative (“disabled” is affirmative, though the same sense can be communicated by the single negative “not enabled”.)

Re: How to Make Other Developers Hate to Work with You

#118

Post by timw4mail »

blindwatchmaker wrote: post #85

Re: documenting code, I've gotten a lot of conflicting advice over the years, with some people insisting code should be documenting, and others insisting on docstrings.

Best to have a balance, I think:

For loosely typed dynamic languages, docblocks on interfaces (function/method definitions, interfaces, etc) are a good idea.

For languages that require types in their interfaces, it is helpful for larger units(classes, functions, methods) to have a summary comment.

Inline comments are still very useful for explaining how and why of implementation details.

While I reject the stance that you should never have comments, I also see cases where better names and simpler logic can alleviate the need for more comments.

Re: How to Make Other Developers Hate to Work with You

#119

Post by stcredzero »

Dzugaru wrote: post #65

> Developers can’t easily go back to where they were right > before an interruption. They need to get into the mindset > for development and then slowly trace back to where they > left off. And every fellow developer knows that. I used to think like that too, but after 10 years programming in many environments, now I'm inclined to disagree. If I cannot refocus immediately after interruption - I know I'm doing somethi…

If I cannot refocus immediately after interruption - I know I'm doing something wrong.

This can be a sign that code needs to be reorganized. I've seen a number of really good coders in their 20's who are admirable for brilliant insights. However, they fall into this pattern of thinking of themselves as invincible, and they take on tasks where they are doing the "heavy lifting" of remembering tons of details all at once.

If you can lift 400 X's by hand, then you could easily lift 4000 X's with the right tool.

One of my bosses kept a stack, explicitly, and used that to keep track of his excursions into sub and side tasks.

I used to say that being a good programmer was being a professional forgetter as much as a professional memorizer. Basically, you should be constantly reorganizing your code as you go, so that there's no danger that forgetting a detail will result in an error. In a way, it's like people who work on high platforms who take precautions so that one drop or one slip won't result in injury or fatality.

In other words, work smarter, not harder.

Re: How to Make Other Developers Hate to Work with You

#120

Post by stcredzero »

lolc wrote: post #113
Dzugaru wrote: post #65

> Developers can’t easily go back to where they were right > before an interruption. They need to get into the mindset > for development and then slowly trace back to where they > left off. And every fellow developer knows that. I used to think like that too, but after 10 years programming in many environments, now I'm inclined to disagree. If I cannot refocus immediately after interruption - I know I'm doing somethi…

To me that just sounds like you don't have tasks that require deep thought. And that you've developed habits to cope with interruptions, such as note-taking. To turn a complex thing into a list of simple things can be done by experience as well as by deep thought. But don't think you could get that experience in 5-minute chunks of thinking. To get the experience you need deep thought. Maybe set your sights higher if…

To me that just sounds like you don't have tasks that require deep thought.

If everything you do requires deep thought, this is possibly a sign of bad code design.

Post reply on HN