

Ask HN: Will they hate me? - ThrowawayCoward

I wrote the following letter to my team (only peers, no managers). Does it have a chance of being productive? If so, would I become hated or viewed as a superior jerk? Is there anything that would produce a better letter if it were eliminated?<p>http:&#x2F;&#x2F;pastie.org&#x2F;8287095
======
EllaMentry
Honestly this does not read well. You have some decent points (not unique
points to any professional software engineer but good points) - there are
several grammatical errors "to(sic) much magic" and you have not provided any
examples.

You state that you are new to the project - from the writing style it sounds
like you are fairly young, so I would guess this is your first programming
gig? Either way take a professional writing course.

Provide examples - where are there problems with code clarity? Where are the
repeated sections? Simply stating there are problems help nobody - you need
data - how many repeated lines? What is the overhead of this code? How many
special cases etc.

Good luck!

~~~
ThrowawayCoward
Thanks for your review! I'm aware that they are not unique points. They all
come either from hard experience or from things I've read from people I
respect over the years.

It's not my first programming gig, and as for young, it's relative. I'm in my
early thirties. Unfortunately, I am the most senior person there.

I am surprised my writing style would lead anyone to think I'm young. Are
there any specifics there? I have taken professional writing courses, but
writing is still something I try to improve. I will keep the suggestion of
enrolling in one in mind, though!

That particular gramatical error was really a typo. Either way, if I decide to
send it at all, I will definitely be proofreading it again. Even though I re-
read it once, I missed that one and would probably have missed it every time.

I haven't provided examples for three reasons. First, I'm hoping it prompts
discussion. Second, many of what I would include as examples are things that
either I or they have pointed out previously. Third, it is already very long;
details will bog down the pace. Given those reasons, would examples still
help?

~~~
EllaMentry
That is interesting, from a reread, I would say the "youngness" is a product
of the length and over-descriptiveness.

""Magic" is my term for "I don't know how it works because I haven't taken the
time to figure it out yet" \- it's an attribute of my understanding of a
thing, not of the thing itself; that is, it's the Clarkian definition." \- No
one speaks like that - it makes it sound like you are trying to come across
smarter than you really are - Every developer under the sun understands what
you mean when you say "Magic"

At it's most essential it sounds like you gobbled up a "software best
practices book" and then spouted chapter titles without any context - Examples
definitely help!

e.g. <Module Z> is a great example of why we need to keep our code clean,
since I joined the team no fewer than X lines have been added resulting in
this module having Y different responsibilities - because <Module Z> is so
bloated we have Q different tickets in our backlog which will result in code
changes to it.

<Module T> and <Module R> are a perfect example of where we can utilize code
reuse. Both contain a function Y, which we make heavy use of - we should
consider extracting this into a common library function etc. etc.

If you make an actual proposal instead of a complaint, people are more likely
to listen - it is a lot harder to argue against raw data than it is a personal
opinion.

~~~
ThrowawayCoward
Interesting. My description of magic is there because I specifically see two
programming-related definitions.

When used with Rails, it's usually derogatory, and it means something like
"something tricky or obscure and complex that is done in order to provide an
easy interface", and in that sense, it is usually derogatory and used when the
someone believes there is a straightforward way that may be an even easier
interface, or is at worst, not much more cumbersome than the interface that is
presented.

The other definition - the one I used, is, for example, how many developers
would answer "How does the Linux syscall mechanism work?" In that case, the
syscall interface is very much needed to provide an easy interface, and it's
not incredibly complex.

One often seems like the other until you look into it, but I still think they
are separate.

------
tjr
A lot of how this is received may depend on the role you have in the group.
You state you are new to the project; were you brought in as a junior novice?
Or as a seasoned professional? If the former, then you might consider
presenting these ideas as suggestions rather than as a critique.

I think, though, that either way, this is a lot to digest all at once.
Breaking this apart into separate communications might be easier to grasp.

Generally, it sounds like your team needs some sort of coding / development
standards. Until a behavior has been established as "correct" or "incorrect",
it's all a matter of opinion.

~~~
ThrowawayCoward
I'm new to the project, but not new to the company. My previous role was a
project lead, and I interacted with this project on a regular basis. I was
brought in to this project to get stuff done because it's very behind and new
work is piling up in the future.

I agree that it's too long. If I send it anything at all, it will have to be
shorter or in segments. Based on this and other peoples review, I probably
won't send it. Still, it helped my identify the issues for myself. There must
be ways of getting results without sending this, and I'll continue to consider
that as I work with the team.

I suppose I really would like these ideals to be a standard.

Thank you for taking the time to read that novella and to post your thoughts!

------
bobfirestone
Yes you will be hated and it won't change anything.

There are members of your team who will agree with some or all of the points
you make you will still be known as the a-hole.

Additionally that is just way too long to be persuasive. Most people won't
read past the first paragraph.

------
gus_massa
For context: When has the project started? When did most of your team come
together? When did you enter the team? How many working experience do you
have?

Most of your ideas are right, but in real world sometimes you need to make
exceptions. For example sometimes you must add a special case. It makes the
code worst, but sometimes something has to get fixed _now_ and cleaned after.

I recommend you to read: "Getting Things Done When You're Only a Grunt":
[http://www.joelonsoftware.com/articles/fog0000000332.html](http://www.joelonsoftware.com/articles/fog0000000332.html)
(don't forget strategy 6)

~~~
ThrowawayCoward
The rewrite started a year ago. It's the _fifth_ version of the same product
that is only four years old. I joined this project about a month ago, but have
been working on a related project and interacting with them for about three
years.

I agree that sometimes things have to be fixed now and cleaned later, but it
should make you feel a little bit queasy when you do it, and you should be
aware that you are adding future work to the project.

I skimmed that link and it looks great, I'll be diving in fully. Since I've
seen the posts from others and was leaning that way already, it's likely I
won't send it, but I really want to push this project to be better. Since you
suggested strategy 6, I read that first, and it's awesome and difficult. Part
of being new means that more than a usual amount of my development time is
spent understanding the project. I've felt rather unproductive because of
this.

Thank you.

