Other programmers on your team hate when you do this!

#shorts #programmers #programming #programmer #softwaredeveloper #softwaredevelopment #softwareengineer #developer #developers

[stevejohnston]

Jamie,
You are so right. I started programming 50 years ago back in 1972. At today's rate of change, all that you know will be obsolete in 5 years, but being a nasty self-absorbed person remains for a lifetime, and is remembered by all.


Regards,
Steve Johnston

[soberhippie]

Yeah, I heard of that

What's even more irritating is when those people want you to skip to the next bit of your explanation of the solution because they "get it". First, there's no guarantee that they do, second, it messes up the mental plan of what you were going to talk about

[andud]

There is always (yes intended generalization) a trap for devs coming from medieval projects, that they will always look at stack as something carved in stone rather than searching for opportunities that come with refactoring. This is a very thin rope you need to balance yourself on not to be condescending but also motivate people to listen to You (before they will pack themselves into huge tech debt)

[the_stygian]

I absolutely feel this.

I've usually tried to make a habit of listening, noting questions, and then afterwards asking, "Hey, I know this and this, but could you tell me some more about this?" Even if it's something I have a bit of background in, reviewing tech and concepts from another team member's position usually reveals a new facet and engages your team.

In my experience, quite often a lot of other more "human" considerations get waylaid by the need to add value and present competency.

[puhrxut]

I would like for once to be on a team where the "developers" have the initiative to learn new things. When I first started my job 23 years ago and I was introduced to IBM assembly, I didn't freeze up and start asking tons of questions, I took the assembly book to a private location, had the print out of the program and learned what it was doing line by line.

[manonthedollar]

I only program as a hobby, but in my profession, I keep this in mind whenever I start a project with a new team. I noticed about myself that I would tend to say "Oh yeah, yeah I've used that before" or something else unintentionally dismissive, because I didn't want to come across as unexperienced. But I now make it an effort to suppress that and to just politely listen, because at the least, it helps to reinforce what I already know, and at the most, they'll throw in some nugget of knowledge about something I "didn't know that I didn't know." Either scenario is positive for me.

[DuRoehre]

Yeah. Similar can be applied to people who don't listen to questions or cannot imagine any other interpretation of a question than the one which fits their mental model (while having advanced knowledge of the topic).

It's sometimes just ridiculous. Example: somebody explains to me or my team his/her stack for foobar. Then there is one little bit missing in the explanation, for various reasons: maybe because the explainer considered it "obvious" or because he used ambiguous wording where his/definition was differing, whatever. Then you ask the explainer about that specific bit. But instead of a little chit-chat to pinpoint what exactly wasn't understood, the explainer rolls her eyes and starts from the start again, from bits and bytes. THOSE people drive me nuts, especially when they go into "combat rhetoric" mode, pushing their speech out without any breaks so that you cannot interrupt them, and you sit there, thinking "oh please, you little s*er, we got it the first time, stop wasting another five minutes of my live".

[megalodon]

I do agree with you and like your approach, however, my current project lead simply loves to explain standard things like they are rocket science (like how you would use some hash function to create a signature for some payload). On the other hand, if I recommend that we look into some 3rd party API or suggest we gather data from this or that source, it's like I'm talking to a potato - no response and complete disregard.

I simply find these kind of people quite toxic and utter narcissists. I don’t think their behavior should be encouraged because they are making everyone else compromise and pent up the frustration. For me, it’s clear these people are not really team players, but fancy them selves to be smarter than everyone else. The people who just like the technology and want to share the knowledge would prepare a short presentation and invite anyone who is interested, I think this is a better way to do it, instead of forcing someone to listen to what they already know and worse yet, get offended if they tell you so.

[go_better]

You're saying interesting things. Sometimes with legacy, it's worthy to at least upgrade... To break free from the status quo echo chamber. From being enchained in stable concepts. I tried Kotlin after Java and now I don't want to go back anymore. Or, I bought myself a good monitor and I don't understand how I've been living without yeah, before the change - everything seems, feels "already fine".

[nvictorme]

No one is an expert at everything. You don't know what you don't know. Always be humble.

[thomas.thomas]

while i agree with your spirit, there also shouldn't be any time wasted about listening to something you already know about
no need to pretend there is some explaining going on if really they are just telling what they themselves learned

[CodingWithUnity]

I would be so happy if my job would hire someone who knew enough to act that cocky.
Im sure it gets old, but it gets just as old having your management hire people who cant do basic junior task.
Or everything they do is just a hack to make it work that probably broke 3 other things that will be on the task list in a few days.

[perfectionbox]

But putting people down is a cornerstone of the industry 🤣

[jamesspinella]

I'm one of those people who literally doesn't have a favorite OS. Desktop Linux distros, macOS and Windows all have unique advantages and disadvantages. If I start at a new company I take what most people have. If everyone is on a Mac, I'll get a Mac too, but it's not my default choice as I think it is for many/most SWEs out there.

I feel the same way about how we solve problems and design solutions. There are often many ways to (and I hate this expression) skin a cat. I've worked with developers who seemed to think there was always a "best" option and I just don't think that's the case. Sometimes, in fact many times, there's literally NO REASON to pick one option over the other. Most recently, this came up with the two SQS queue types in AWS. For what we needed to build, it made no difference whatsoever whether we went with Standard or FIFO. The messages could be delivered out of order and more than once, and there wouldn't be a whole lot of messages/s coming through anyway.. so which do you go with? I guess whichever one is cheaper, but the price difference is so small that's barely a reason.