[therealplato]

I consider this essential: The ability to decouple the task from your ego.

Specifically:

- Never say "Got it" or "OK" when someone is explaining a problem or solution and you don't follow. It feels awkward to say "Sorry, I'm still not following. Do you mean that when..." five times in the same conversation but it is worth your time and embarrassment to come away with a correctly framed and well understood situation. Otherwise you will figure out what they meant after wasting hours/days/months solving the wrong thing.

- You'll be faced with situations where your colleagues/organization expect you to implement solutions you think are not the best. Understand that "the best way" for the team or business is not necessarily the same as "the best way" for you personally or "the best way" overall. You are likely missing some context about the choice. Be mindful of reputation risks, time costs and maintenance costs involved in changing the approach.

When you're asked to code something you don't agree with (including ethical issues) your options include: silently accept their approach, refuse to do their approach, propose an approach (with conversation or code) and gracefully accept the result, or find another job. Be aware that different organizations will react differently to those approaches. Under no circumstances should you fall into the trap of spending a week to convince the team to adopt a change that would save a week of costs.

[sixothree]

I've never mentally dinged someone for saying they don't know how to use a particular technology. This field is immense and there is no possible way for any person to understand it all.

But when someone said they could do something a particular way and the results suggest otherwise I find it completely frustrating.

[logicOnly]

It's extremely hard to prove things in programming.

You can either develop both options and pick the best, or you can use "best practices", which is non scientific. Authority and tradition make best practices.

Also "don't @ me" about basic logic like nested loops and bigO. That's not what I'm talking about here.

[jl2718]

Most coders I see give up on asking clarifying questions because they realize quickly that the answers aren’t there, and they never will be, and this is somehow okay to the person who is telling them what to do.

It’s really obvious during remote work: PowerPoint then silence, then a bunch of assignments handed out. If you ask any one of the audience, coder to coder, they all have the same confusions; some write a fancy class template like ‘ProblemSolverObjectDispatchFactory’, others just ignore.

[almog]

>> You are likely missing some context about the choice

If it's a product/business decision and you care about that aspect of your work, dig down and understand the context, otherwise, before long you're likely to grow numb to that aspect of your work.

[ethbr0]

This 1000%. If you're in a business-interactive role, ask about the business as time permits.

People like to feel like an expert, and will usually be happy to explain.

It will make you better (knowledge transfer to unrelated problems), your code better (domain knowledge), and your relationships better (recognizing your colleagues as peers with different skills, not just not-your-skills).

[austincheney]

Absolutely.

As a front end developer your existence is ultimately defined by your grasp of very few tree models, namely the DOM but also the file system and various similar concepts when writing systems automation. It is common for developers to not grasp the concept of implicit relationships, which are a fundamental consideration of tree models.

This is basic stuff, the foundation that defines your career. And still many developers do not grasp it. They spend so much of their careers hiding from the core concepts of their jobs dependent upon abstractions to reframe the technology.

What may begin as embarrassment evolves into stubborn resolution masking extreme insecurity. Everybody can see when you are embarrassed, insecure, and when you fail to understand something. So many times people will try to redefine an important problem to appear less lost or hopeless. When other people are really listening they can see through it. It’s only a shallow self-deception.

It’s okay to not know something and need help. Pretending otherwise is poor character.

[tiku]

Agreed. understanding the problem is a big thing. Then explain it back to them, perhaps offer them a better solution if you can.

Asking questions is the way to understanding.

[daveslash]

This. I immediately develop deeper respect for a colleague when they interact with me this way. (Assuming it's not me who's not following - that happens plenty too!). When a colleague, including junior devs, ask questions and dig in, I interpret that as thinking critically about the problem and digging in. That's exactly what I want out of engineers.

[collyw]

> Never say "Got it" or "OK" when someone is explaining a problem or solution and you don't follow.

The absolute worst is when a colleague does this on your behalf.

[benhurmarcel]

That doesn't seem specific to programming. You could say the same thing about mechanical engineering for example.