Ask HN: Engineering managers, what do you wish more developers understood? - jamestimmins
======
sloaken
Two things:

1) its not personal, its about the money. thats why we have to do this / that
etc, and not this or that

2) everyone is replacable (or will choose to leave at some point) - make your
code / system / database in such a way that your replacement admirers you for
the clarity of your documentation, not hates you for that clever trick you
implemented. Corollary: all code that is not well documented is throw away
crap when you leave.

------
aliveornothing
I ran a software company and a team for 4 years, here's my experience:

1\. I'm in this with Sloaken, it's about the money. Code artesans won't make
it in the real world. I mean, you might get very lucky and have a huge budget
and all the time in the world, but unless you count on winning a lottery it's
not happening. Deal with it, it's about making money with the code, not vice
versa.

2\. That one little extra thing you decided by yourself to code turned into 2
bugs, 4 feature requests, missing documentation and a duplicate tool library
since another developer / team was working on something similar. In other
words: don't go solo.

3\. Getting shit done is the number one quality of a developer.

4\. This is more towards designers but applies to developers as well: The
customers' opinion about our UI/UX comes first, your opinion second.

~~~
scalesolved
1\. Totally agree, you've gotta work with constraints and engineers need to
work towards generating revenue for the business as the primary goal.

2\. 100% agree.

3\. Getting shit done usually means things done shitly. It's the point you
made I disagree with the most, whilst I understand the sentiment is towards
engineers that complete tasks I feel that usually expressed this way (and
coming from an engineering manager perspective) is that they favour the happy
path engineer who completes tasks quickly.

Need authentication in your app? They'll have it done quickly and it'll work
for the manager happy path and they'll already be onto the next task. To the
manager and whatever task tracker you have this engineer will be the 'one
getting shit done' but to the team and velocity they'll be the one leaving
exploits, broken functionality and zero tests/documentation.

I'm guessing your sentiment was more along the lines of 'developers who
pragmatically take on tech debt to deliver crucial features earlier to impact
the business bottom line whilst planning to pay off the debt in a timely
manner'. Long winded I know :)

4\. This can be tricky, which customers to please and follow? A good designer
allowed to come up with a consistent vision will most of the time be more
productive/pleasing than following the changing opinions of your customer
base.

------
hkarthik
Couple of things I can rattle off:

It takes a lot of work to make a technology production-ready. I've seen MySQL
go from being derided as a toy database, to powering some of the largest,
highest scale consumer apps out there. It took years of work from both the
core teams, and many contributions out there from people working with it every
day to make that possible. It's important for engineers to know their history
when they pitch the latest tech they read about on HN and ask why they can't
use it on a new project at work. The fact that you can get it up and running
isn't enough, you need to be able to keep it running. If you aren't willing to
put in that work, then don't pitch the tech.

Secondly, emergent architectures are often more resilient than deliberate
architectures. Frameworks and platforms extracted out of real products tend to
have more longevity behind them than those that are deliberately designed to
solve a multitude of needs from day one. If it doesn't feel right to bring a
library or platform in to solve your problem (rather than build something
yourself), then don't do it. You might find yourself spending more time
fighting the platform or bending it to your will than by building something by
yourself.

------
Jemaclus
There are five things I wish developers with whom I work understood:

1) At the end of the way, we're a business. The purpose of the business is to
make money. Not work on cool things, not release a cool product, but to make
money. It's not about experimenting with the latest, greatest technology all
the time. If we don't make money, you don't have a job.

2) I'm juggling a lot of priorities, and I've _always_ got the bigger picture
in mind. The tasks I assign you might seem dumb or not useful in the moment,
but trust me, either someone is _paying us to do this_ or gets us closer to a
goal on our roadmap.

3) I believe as engineers that we have a unique skillset among most people in
our respective industries: we can automate repetitive tasks. Automate all the
things. Most of the time, it will make all of our lives better.

4) As a corollary to #3, I wish more developers were willing to adopt a
mindset of being willing to shoulder more work to make their colleagues lives
easier. In 95% of cases, I would rather that my team take on the burden of
doing X, Y, or Z, because I know we can automate it. Not only does this earn
goodwill among the rest of our company, but it makes us look like absolute
powerhouses of engineering.

5) Delete the phrase "it works from me" from your vocabulary. People don't
complain about things that work for them. If it works for you but not them,
then there are two possibilities: there's a bug or the user is doing something
wrong. _Always_ assume that there is a bug, unless proven otherwise. It's just
good, professional communication policy.

------
gesman
Get developers more into creative "what if" thinking.

Quite a few are like robots that needs to be told what to do to the letter.

