
Lessons from Design School for Software Engineers - ingve
https://stackoverflow.blog/2019/10/09/lessons-from-design-school-for-software-engineers/
======
ahuth
As a software engineer, I've always been fascinated by the amount of critique
that designers go through with their designs. While we do have code review,
I'm not sure our architecture/design choices go through the same level of
scrutiny. And I wonder if we'd be better of if it did.

Having said that, I'm sure it's a double-edged sword. No one wants to feel
like someone is tearing apart their code.

~~~
rahimnathwani
Some places have 'engineering design documents' which are written early,
shared widely and invite comments. It's much cheaper to spot issues at this
stage than once a lot of code has been written.

~~~
pavlov
I always write a design document first for anything larger than a few days'
work. A few pages of prose is enough, written in Google Doc or Quip or
whatever is the comfortable sharing+commenting standard within the org.

Even if nobody else ends up attentively reading the document, it's valuable
for myself as a point of reference after the work is done. It can be humbling
to go back and read my own assumptions.

Usually some of the text can be transplanted into more permanent engineering
documentation (Wiki or whatever), so it's also a good habit for documenting
beyond just inline comments.

------
bluesnowmonkey
> Have you ever met somebody who was always against exploring suggested
> changes to their code in a pull request? Perhaps they got upset if somebody
> else went in and refactored some code they worked on in the past?

There are at least three dynamics going in here that overlap and get conflated
frequently.

1\. Ego, inability to accept criticism. Obviously this is just something the
engineer needs to grow past.

2\. Sometimes another engineer not familiar with the codebase will do a drive
by commit. They need to make a specific change and find the code around that
change to be confusing, so they refactor it to be easier to understand in
isolation. However they don't understand the idioms and patterns of the
codebase as a whole, and the net effect is that the system as a whole becomes
less coherent and maintainable. This creates both-sides-are-right arguments,
like, "Yes you did give that variable a clearer name, except we use the other
name consistently everywhere else, so if you rename it here you should rename
it everywhere, and it's not really worth doing a such a big refactor and
invalidating everyone's familiarity, is it?"

3\. Familiarity. When you work in the same system for a long time, you develop
a mental map of how everything works. That map can be a source of great
productivity. Sometimes it's actually not worth making an improvement because
it will necessitate the long term maintainers having to relearn how things
work, and they have other things to do more important than this improvement.

------
collyw
Any advice for dealing with co-workers that are too attached to their code?

------
hellothree23
lesson #6. quit design school and buy $100 worth of course work on Udemy.

