

Ask HN: Should I get mentored by this guy? - anupshinde
http://pastebin.com/ADBRG5zr

======
jmduke
It's hard to judge this objectively, since you seem to be painting your
differences from Mr. X in a particularly "new v. old" light.

A few examples:

 _X says that we should be using "special character" separated strings -
without using a lib/wrapper that hides the underlying implementation._

Why does he think that way? Has he tried going down a JSON route before, only
to be confronted with an edge case or peculiarity that makes his method
simpler?

And this part jumped out to me:

 _For example, I say - Let 's put in 10 more days and make a generic solution
to create similar forms for 30 db-tables ... (time is not a problem)_

Ten days is a lot of time. Can you put together an argument that the generic
solution is worth that time even in the very long run? You say time is not a
problem, but how is that possibly the case?

~~~
pmelendez
>"Why does he think that way? Has he tried going down a JSON route before,
only to be confronted with an edge case or peculiarity that makes his method
simpler?"

I was actually about to comment on the same thing. Depending on the case a
simple solution would be faster to implement and potentially easier to
maintain, but as always it will depend on the requirements

~~~
ks
If you have a flat structure (similar to rows in a database table) nothing is
simpler and faster to process than a tab delimited file (or CSV).

~~~
pmelendez
Exactly my point... The motto of keep it simple what is simple generally
works.

------
zwieback
Here's my breakdown (disclosure: I'm an old fart but used be a young gun)

JSON: go with the more standard JSON, "special delimiters" sounds brittle -->
old fart loses

customers: don't solve their problem unless they paid for it or it's very
small (<1hr). If it's a good customer they'll understand, bad customer will
ask for more and more --> old fart wins

functionality: restrict if it's a headache to support unless it's something
everyone else has already has --> tie, old fart and young gun should discuss
it

genericness: big warning sign! In my first few years I was always building
frameworks, now I solve problems. When the time comes to build a framework
you'll know it but it takes many years to develop that wisdom --> old fart
wins

To make matters a little harder the old fart seems to naturally have
encyclopedic knowledge or was forced to develop it in a day and age of printed
manuals (I remember those days and am glad they are gone!) The current
generation of programmers has less need for rote memorization but keep in mind
that there's some value in encyclopedic knowledge beyond the pure facts. If
you know a lot of stuff without having to look it up your brain also becomes
better at algorithmic thinking because you have more data to practice on.
Sadly, my own memory has never been so great.

~~~
ori_b
As far as JSON, this is the part that's telling to me: " _without using a lib
/wrapper that hides the underlying implementation._" It sounds like he's
arguing about generating it directly and parsing it by hand, although without
context, I can't say for sure. If that's the case, I'd say the old fart is
right on this one.

As far as facts, if you know a lot of facts, you can reason about how changing
one fact (eg, "we write this value to this SQL table here, and we are going to
stop doing it") allows you to reason about how other facts are affected
("Modules X and Y expect that data to be there").

~~~
rob05c
> As far as JSON

I wasn't clear on that example. If he's talking about CSV, there's nothing
wrong with that (though I wouldn't call JSON "bad"). If he's talking about
delimiting text with the bell character, yeah, that's ghastly.

> without context

I feel like most of the examples don't have enough context to make a fair
judgement.

If it's just a small amount in one place, simple formats like CSV and JSON can
easily be parsed, and especially generated, manually. If they're used all over
the codebase, manual parsing would create a huge amount of duplicated code.
There just isn't enough context.

------
electrichead
These are interesting scenarios. Each of them could probably use some
additional context but overall I think the problem is one of practicality vs
idealism. I have been in both parties over the years and have more often than
not been in the camp of over-architecting a solution. I think that on the
surface, he does sound like a very practical programmer who is cognizant of
the bottom line. If you are not going to be paid extra to implement something,
then sometimes it doesn't make business sense to implement it. It is sad but
true and you will sometimes feel the same if freelancing. To me, I would not
turn my back on this guy - it does seem like there is stuff to be learnt from
him. Nobody has all the answers though, so it is good for you to question him.
If it is possible, maybe open dialogue with him about these would be
beneficial to you both.

~~~
ebzlo
I agree with this response. Specifically highlighting the problem being a
matter of practicality vs idealism. One of the things you learn as a young
programmer is that bad code is inevitable when your resources are limited.

A practical generic solution, for example, that takes an extra 10 days to do,
sounds fantastic from an engineering perspective-- we're trained to think this
way. But on the business side of things, you may have a timeline for a feature
to nab a client, or not enough budget for those extra 10 days, etc.

My opinion on these matters now generally falls into the _it depends_ camp.
Take his mentorship, because it sounds like he understands that every
engineering solution is accompanied by a business solution and they must be
agreeable for both parties (that said, he does seem a little jaded, so you
don't have to take absolutely everything he says to heart-- there are
companies who will give less weight to the business side of things, but the
reality is that the consideration will always exist).

~~~
pandler
> every engineering solution is accompanied by a business solution

This cannot be stressed enough. Replace "business" with X. Engineering is
rarely isolated. More often than not, constraints on time, budget, usability,
customer relations, etc... are just as important as the down-and-dirty
engineering constraints themselves.

This applies to all engineering. It is much more obvious, in some fields than
others, though. E.g. material costs are easy to perform a cost/benefit
analysis on, whereas software is generally more abstract.

------
smoyer
If you replace "because" with "bcoz", my assumption would be that you're wrong
or sloppy about other things. There was a popular book titled "Dress for
Success" that was all about appearances ... Appearances aren't just looks
anymore and you should be careful how you represent yourself digitally if you
want to advance.

EDIT: Rereading that it sounds a bit harsh ... it's perfectly fine to abuse a
language when you're communicating with your friends (some friends anyway). As
an architect, you've also got to communicate with management. Practice by
playing some buzzword bingo, then write coherent and grammatically correct
sentences using those words. You may in fact be smarter than this architect,
but you have to convince everyone else too. (Actions speak louder than words,
but also choose your words carefully).

~~~
Confusion
Since that is the only example of such language in the post, while there are
many more opportunities for sloppy language, I think he originally wrote it
fast, with more of such abbreviations, and then filled it out. So I think he
just missed one and does care about appearances.

~~~
smoyer
Perhaps ... and he/she may not even be a native English speaker. I don't
generally categorize people by how they talk or write, but upper management
probably will.

------
gkoberger
You don't get to pick your mentors. They just happen. I have a lot of people I
consider mentors, and none were "assigned" to me. And the ones that were
assigned? They tended to be the absolute worst people to learn from, if for no
other reason than they felt they had to impart wisdom and be smarter and
justify being a "mentor".

Learn from him, sure. Maybe that means learning what _not_ to do. But "mentor"
isn't the word you're looking for here, I don't think.

~~~
iurisilvio
That is the answer! I already had this problem too. You can learn a lot, even
if the mentor is awful. You will be challenged a lot to put your point of view
in the code, maybe you even discover you are wrong about your arguments.

If you really think you can't learn anything from him, probably he is the
right person, you have a lot to learn.

------
JonnieCache
He sounds battle hardened (and like he has a mortgage, which enforces a
certain lucidity.) You should definitely listen to him and take him seriously,
if you want to assign him the symbol of "mentor" in your head, that's up to
you.

EDIT: 6-7 years older... heh.

~~~
snorkel
Yes, this exactly. This is partly why engineers have trouble learning the art
of management because in management you have to sometimes put on the business
hat that says do the most expedient thing rather then the craftsmanship hat
that says every project and feature should be treated as an enduring testament
to engineering perfection.

You need to understand more than just the art of software engineering, you
also need to understand the business, the customers, the stakeholders, the
roadmaps, and generally the reason why things are moving in particular
direction. Your mentor should be sharing as much as they know on these topics
instead of just mandating implementation details without describing why.

------
kstop
He probably has a very good understanding of the company's priorities and
politics. Pay more attention to that. Politely disagree on the tech side when
you think it's appropriate, make your arguments, and then implement based on
what comes out of that.

On stuff like JSON vs. custom delimiters, that's old thinking - you can
probably win that argument by finding out exactly why he thinks that way.
Chances are that he's concerned about bandwidth overhead or something similar,
or he's thinking about the effort of implementing it from scratch. You can
argue against the former by doing some tests with your webserver's mod_gzip,
and the latter by coding up a POC with a JSON library and showing him how easy
it was.

Being mentored doesn't imply that you have to take everything they say as
gold. Approaching their advice with a critical but respectful attitude is
probably best.

------
dasil003
I'm skeptical about a developer who doesn't like JSON, however it's not clear
what his reasoning is from this little anecdote. Maybe there's already a large
amount of code using the custom method, maybe the data is not that complex and
there are layers that don't have ready access to a JSON parser.

A lot of the rest of it sounds like simple pragmatism and YAGNI which is
something many young and brilliant developers need to learn. That said, if he
lets copy and paste code multiply and not be refactored and relies on his
perfect memory of the codebase to update multiple places then that could be a
red flag.

Anyway, if he has the patience so explain the reasoning to you and gives you
some war stories I think you'll come out better for having listened.

~~~
alexchamberlain
Maybe they are dealing with a few gig of CSV time series?

------
skrger
It's very hard to impossible to really judge based on these short examples but
I can totally relate to both of you. E.g. if you see a feature that seems to
be free in terms of coding it is very hard to resist offering it. If you do
that over and over you realize there are at least two problems with this:

* It's never free. Do you have tests for this? + it will restrict your way you can refactor the code.

* Product features are not always good, product complexity is actually a bad thing and it is unlikely that you don't increase it.

That said, it will make some users happy, so it may be worth it - all I'm
saying is that this should be a conscious decision, it isn't a no-brainer.

------
ktrgardiner
Mentorship does not mean being reshaped in the form of your mentor, as if you
are supposed to become a carbon copy of them. It means learning from someone
more experienced than you in a more controlled environment. And not just
learning from situations you wouldn't normally find yourself in and thus
benefitting greatly from specific context, but learning from a different
perspective that you can incorporate into your own. You are being given an
opportunity to grow and diversify your way of thinking and executing. Embrace
it.

~~~
toblender
I agree, don't put them up on a pedestal.

Mentors are human, they are far from perfect.

It maybe a good idea to get a Mentor for different aspects of your life. Pick
and choose the talents/qualities you want to emulate, don't just copy and
paste their actions and beliefs.

------
jakejake
The tech lead sounds like a very pragmatic developer who just wants to get
work done quickly without hassle. This is not necessarily a bad thing but it
does not mean he is always right either. He probably has most likely opened up
a few cans of worms and as a result is very conservative in his approach.
Younger people tend to bring a lot of energy, but sometimes come into a
company and want to shake things up - then they get bored and leave a bunch of
fad-oriented programming code for the remaining team to maintain for 5 years.

The copy/paste would be a warning sign to me, but it could also be that he
knows a generic solution would become extremely complex with problems that you
do not yet have the experience to forsee. It's not really possible to
understand which is true based on your email.

Anyway, I would try to get more information from him to see if he is being
lazy or pragmatic. When he says thing that you disagree with - have him
explain it to you. It might be that he has very good reasons - or that he is
just resisting new technology that he doesn't understand. I would try to find
that out first.

All that being said - you can learn a lot from a bad situation as well as a
good one. You can learn what not to do!

------
cmiles74
It's hard to characterize someone based solely on a series of vignettes but
they do seem a bit familiar. I've worked with people that seem similar to Mr.
X and, at least a couple times, have had to report to someone like him.

In my opinion it's important to keep one's idealism and practicality balanced.
For instance: solving the company's problems first and letting the customer
solves their own strikes me as both practical and reasonable. Opening one's
mouth and recommending that code be literally cut-and-pasted repeatedly may
sound practical, but in practice I've learned that's rarely the case.

I think the perfect mentor is nearly impossible to find. I believe that I've
been well served by reporting to a variety of different personalities and
striving to emulate those things that, as far as I could tell, where helping
them succeed. That's a bit of a punt, but I don't think there's an easy answer
here.

------
nbuggia
I think the answers is Yes, absolutely. But I think I have a different idea
about what the mentorship should involve then you do. I think you can learn
more from studying his thought process and his experiences with sr.
management, customers and partners then you will from simply following his
technical suggestions.

I also think you should bring a couple things to the table that you want to
teach him. It could be some new fancy tech, or some online community or
something that will help expand his perspective and better understand where
you are coming from.

At the end of the day, it is really relationship problems that hold us back -
not technology problems. And your ability to form successful mentor/mentee
relationships will help you much more in the future than learning new tech of
the week. (It will also give you perspective when your future mentee posts to
hacker news v.next about her stodgy old mentor that doesn't know anything ;)

------
avalaunch
Like others have mentioned, it's hard to know which approach in each of your
examples is best without digging in more.

Assuming his approach is indeed better than yours, what I'd be worried about
is that he hasn't explained to you why his approach is better (or you weren't
listening). A good mentor needs to not only be able to do things the "right
way" but also articulate in an easy to digest manner what makes it the right
way.

You need to express your desire to learn from him and ask him to explain why
his approach is better. If he can do that well, then he'll be a good mentor
for you. If not, then not.

------
hoopism
This guy is crazy... seems like he's trying to get stuff done in favor of
engineering new problems that require more technology and longer development
time...

Kidding aside... I think by posting this you already had your answer.

------
latj
1\. Respect and learn from everything mentor says. 2\. Try out all the things
mentor suggests that you have time to try out. 3\. Throw out everything and do
what you think is best.

Sometimes you'll be right, the clouds will part and you will feel the warmth
of the sun on your face. Other times you'll be wrong and will humbly think
"mentor was right that time".

But, at the end of the day its your name attached to those lines of code, its
your career, and your life. Survive by your own cunning.

And, while we're doling out life advice- I strongly suggest standing up often.

------
alexchamberlain
I'm not the most agreeable person in the world. I don't really like being
disagreed with and I like to do things my way.

I've learnt 2 lessons: I'm not always right and you can agree to disagree. Ask
questions such as "How did you reach that decision?". If they can't convince
you, calmly give your reasoning behind your decision. Worst comes to worst,
agree to disagree and let your line manager make a call. Go with it and learn.

------
meric
There's something to learn from everyone. I suggest if you find yourself not
agreeing to his advice, keep it in your head anyway. When you find yourself
facing a problem his advice described (and you aren't working with him for
that problem), think about ways his advice would apply, and ways his advice is
not relevant, and make your own decision.

Learn, but be yourself, at the same time.

------
dec0dedab0de
I'm not a developer, but I've had a very similar experience. It sounds like
Mr. X is just trying to minimize the amount of work he has to do. Usually in
these circumstances experience wins, especially if you want to have a personal
life. Don't stop suggesting change though, just get used to the idea that only
your best ideas will make it through.

------
djvu9
The truth is all the good stuff you mentioned / believed in is not important
or even irrelevant in a lot of contexts. Try to learn from him on judgement
within a context, instead of sticking to whatever fancy things/rules you learn
from a textbook or the internet.

------
jaggederest
3-4 releases a year is a red flag to me if you're not shipping something
physical to update.

That said, you can learn from almost anyone - talk to him a lot about the
reasons _why_ he makes decisions, not the decisions he makes.

~~~
marcc
3-4 releases per year should be a red flag, but unfortunately it's atually
pretty common in enterprise environments. Hopefully they are shipping code
much more frequently, and packaging it up and calling it a "release" every 3-4
months.

~~~
aferreira
Odd, I've been making releases of my product at least twice a month for the
last year, and it's been increasing steadily lately too. I always thought it
was a good thing?

~~~
recursive
It might be a good thing or bad thing depending on the expectations of your
users.

------
logicallee
I think you should listen to this guy, because while you're busy making
something generic, he's changed it ten times and cut and paste it after each
change.

You need to be a lot leaner and then make things more ideal when the code-base
freezes: which is never.

For example, with JSON is nice if you're sharing data with others. But parsing
anything can be done in half a minute by hand.

Likewise, if you start making changes that should be on the buyer's end,
you're now consulting for free instead of working on your product.

etc etc etc. I say go with him.

After learning everything he has to teach you, you will find that some things
are still easy to do your way.

The reason he REMEMBERS where you don't is because he's thinking leanly about
the actual feautre; he doesn't care what the code looks like (within reason)
to support it.

------
jayroh
There are arguable shades of gray in those examples but the JSON one and this
one:

> X says - Lets make those by copy-pasting - and later we will think about
> making it generic

... are pretty ill-informed. That just reeks of sloppy and lazy and not
particularly concerned about his craft. If you're looking for a mentor I would
think you'd want to align yourself with someone who is mindful of their craft,
no?

~~~
dreamfactory
I hate this knee-jerk response so many have that copy/paste == bad. You aren't
in any position to create a generic API until you have at least 3
implementations, so unless it's a very obvious solution service, or you are
practising some kind of extreme waterfall, copy/paste could be the best way to
go. I'll hypothesise that most of the architectural problems we have are down
to the cult of prefactoring.

