

How not to think like a programmer - akshayshinde7
https://medium.com/@semicolon_sucks/how-not-to-think-like-a-programmer-2a147f2221b6

======
timrosenblatt
Akshay, it looks like you're the person who wrote this and posted it. Thank
you for the contribution. It deserves to make the front page.

This is insanely important and may be the best HN link all week. Any engineer
who routinely feels frustrated when working with other people should pay
attention to this.

I've done engineering and sales, which are very different skillsets. More
importantly, I have been mentored by other people who are world class at these
respective skills, and have been very lucky to have the opportunity to learn
from them.

Even though not everyone should learn to code, it is valuable to be able to
put on the other person's hat.

Non-engineers need to respect that engineers deal with situations that don't
happen in everyday life. An engineer is frequently presented with situations
that boil down to "it does work" or "it does not work". There is no gray area,
and typically the computer is not very polite in the way that it tells you
that you're wrong -- errors rarely say "Hey, I hope you aren't upset about
this, but something's not working right. Want to talk it through and find a
solution?" Instead, we deal with messages that have the emotional sensitivity
of "screw you!", or if we are _lucky_ , "screw you! #32"

Being in this mindset all the time will condition you to thinking in a certain
way, and that's what is required to program. People, on the other hand, don't
work like this, and if you can see the difference and act on it, you will
benefit from it.

~~~
akshayshinde7
Thanks man. I totally agree. Sometimes I still get frustrated while speaking
with clients and it takes huge amount of efforts to convince myself to look at
things from the client's perspective.

------
macpheec
The point driven home by this article is really about how to transition from
being an agile problem solver to a product designer/manager.

~~~
akshayshinde7
When I started to write the article this is exactly what I was trying to
convey. But over time I realized that even when you are working as a full
stack developer, you need to understand a software product's other aspects
apart from coding to build a great product. Otherwise you are just building in
vacuum which I think is the wrong way to build anything.

