Live data from Hacker News

How to Make Other Developers Hate to Work with You

anaxi.com

161–170 of 191 posts

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

#161
post #38

Earlier quoted context omitted.

Software development is the continual discovery that you were an idiot two weeks ago.

God knows. Especially when you're new like me. I go back even after a month and "Oh man I'd never do it like that again." No to say it didn't work or was even bad but I just found a better pattern to handle that case that I'd use by default now and it changes so much.

I cringe when I look at some code I wrote. Some of it is maintenance nightmare, however, I read a book and found a better way to do some of those things. With each day I get better at writing maintainable code, I do less of duct taping to make things work.

I feel like I'm actually getting good at this software thing, and I'm actually not a total idiot. However, sometimes I look up simple things and I think I'm still an idiot. But when I look at the bigger picture I can see how much I have learned and understand the whole process. Servers, database, software, documentation, good code is great but there is more to software and I love it.

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

#162

Earlier quoted context omitted.

#9 for sure. Probably a side effect of being sloppy or writing bad code.

My version of #9 I'm dealing with is: Is this an feature that a customer will use? Or is it internal improvement? Yes to first, no to latter.

Are you saying that your team hasn’t done enough of the latter, or that they don’t focus enough on the former?

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

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

> "usually leads to components nobody can understand let alone maintain" As you advance up the mountain, you will learn to see complexity simply. When you make this realization, your components will simplify dramatically. You must learn to see simply before you can design simply. It just takes time. There's nothing wrong with this, humility doesn't mean giving up your belief that you're capable of anything. We were a…

[deleted]

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

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

If you think it's a problem that you have this type of arrogance, what are you doing to improve and seek training about it?

I keep in mind that I tend toward arrogance and think twice whenever "oh, I can do that" pops in my head. Also, splitting tasks with a team means other people can grab what they do well and I won't overreach.

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

#166
post #110

Earlier quoted context omitted.

At the point where all your practicing is just maintaining your performance, you've reached your peak. You can stay there, or you can go higher if you practice more (or better). But there is a finite amount of practicing you can do each day. (Studies argue that 4 hours is plenty.) So there is an absolute limit per individual.

Are we talking about a physical skill or a personal capacity for knowledge? Because while your argument might have merit when applied to something like sports, it doesn't hold much water when talking about accumulated knowledge. Yes, I might forget how to do a math problem the way I could when studying for a test in college, but I'll never forget that knowledge exists and where to find it if I should need to relearn.…

Mental performance needs practice just like physical performance. At some point you max out. And if you don't keep up practicing at level, your performance declines. Knowledge too is bound by those rules. We're constantly forgetting as we learn new stuff.

> I'll never forget that knowledge exists and where to find it if I should need to relearn.

Meaning you'd have to practice to again reach your former performance. Sure you may reach your peak level again and reach it quicker thanks to your old practice. But you do need to practice again. And then again, if you want to keep it.

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

#167
post #98

Earlier quoted context omitted.

As individuals, there's damn little we can achieve.

Nobody said you must do it alone.

> doesn't mean giving up your belief that you're capable of anything.

> Humans have the capability to do anything we put our minds to. You can too.

> doesn't mean you're not capable of anything.

That does sound like you're talking to individuals. Turn down the hyperbole a notch and I might even agree

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

#168

Earlier quoted context omitted.

My version of #9 I'm dealing with is: Is this an feature that a customer will use? Or is it internal improvement? Yes to first, no to latter.

Are you saying that your team hasn’t done enough of the latter, or that they don’t focus enough on the former?

We haven’t done enough of the latter. I’d love to automate and improve a lot of stuff but our project manager is pretty much always client visible first.

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

#169
post #113

Earlier quoted context omitted.

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.

Haha, could be yes. And at the opposite end:

If everything I do can be achieved without thinking hard I'll be replaced with a tiny shell script written by someone who does.

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

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

Another one is giving insanely long names but only changing one little part, instead of taking advantage of the heirarchical nature of programming languages and coming up with a nice nested structure. Example:

  class TheRpcThing
  {
    object TheRpcThingHost
    object TheRpcThingHostTimer
    class TheRpcThingValidationException
    {
      object TheRpcThingHostValidationException
      object TheRpcThingHostValidationExceptionErrorMessage
      object TheRpcThingHostValidationExceptionErrorMessageFormatter
    }
  }
The cognitive cost of reading a bunch of previously-unseen code, which has an accumulation (the perfect word for this kind of thing) of the above can be so frustrating.
Post reply on HN