
How to reward skilled coders with something other than people management - koopajah
http://lizthedeveloper.com/how-to-reward-skilled-coders-with-something-other-than-people-management
======
mathattack
When I was at BigCo, they officially had 2 paths - one involved people
leadership, the other technical leadership. The reality was technical
leadership stopped a level below director, and only 2 or 3 even managed to
make it that far. After 3.5 years there, it had a formative impact of pushing
me away from both the company and technology. I recovered on both, but it's
something one should take seriously on taking a job. I'm not sure that
creating "Mega-consultants" works either, as it takes the emphasis away from
delivery ownership.

That said, here are a few ideas in rank order from easy/feasible to
crazy/radical:

1) Technical leaders of a certain level can not be overruled on technical
decisions by non-technical leaders in the department.

2) Encourage the best to share their work outside the firm.

3) Smart people like to be with smart people. Pay up for a culture or cohort
of superstars, not an individual superstar.

4) Provide time and monetary budget for architecture and technical debt that
is owned and allocated by the best in the organization.

5) Allow technical stars to have the ability to change assignments at their
will with a given notice period. (Yes it may cause problems, but the free
market is always giving them offers)

6) Enable managers to raise technical pay without concern for bands. For
example, the VP should be able to say, "I can hire 4 engineers for 100K each,
or I can hire someone in the open market for 200K. Instead I will pay my
internal superstar 220K since she will do it the best, even though it's way
out of bands of someone with her seniority and level."

~~~
thwarted
One thing you definitely don't want to do is take a team away from people who
consider themselves to be engineers who happen to be in a people manager role
(and have been for a long time and are considered by their team and the wider
engineering org to be successful at it). And if you want to do this, you have
to make sure the person, and their team, is on board with making that change.

This can be especially problematic if you don't have a culture of the
organization being driven by engineering; where becoming a "manager" affords
more success (making decisions, getting things done) purely because you're a
manager now (because of the political aspects). Removing the people management
leadership position then can feel like a demotion.

------
zobzu
One thing that always fails with that is that management always get more
money.

Wanna be a tech leader paid 150k? (fancy title, +- same salary as before)

Or wanna be a director paid 250k? (fancier title, way bigger salary)

Kinda difficult not to choose the "free tesla every year" isn't it? Plus.. the
directory job is generally going to mean a more relaxed job (albeit less
interesting for an engineer maybe, but that's why you have open source
projects right?).

~~~
peteretep

        > Plus.. the director job is generally going to mean a
        > more relaxed job
    

If you believe responsibility over people, budgets, liabilities and policy is
less stressful than responsibility over systems, you're high. As a programmer,
let me tell you: people who have only ever done programming for a career have
no clue how relatively easy they have it.

~~~
snoman
I suspect that the reason for the perpetuation of this myth is that, if a
manager is doing their job _really really well_ then all of that stress and BS
is hidden from their directs.

~~~
jghn
Indeed. The best managers I've ever had were the ones that completely shielded
the rest of us from the absolute BS that always exist. Go figure, those were
the companies where the rank & file didn't think political BS existed -
surprise, your manager was protecting you from that!

~~~
solistice
So essentially managers are people sysadmins. They make sure everyone is
working, try to resolve conflicts and ideally make sure that everyone is
running the right tools. What would be a people engineer in that vein?

~~~
jghn
Yes. Although in my case when I was talking about my 'best managers', they
were also the people who were brilliant and were really good at the tech side
too. These people all just had a natural ability to navigate through the
political BS while still being extremely competent software folks.

~~~
solistice
Looks like those people were truly "full stack". From the tech layer to the
interdepartmental layer.

~~~
jghn
Yes, as much as I hate that term it really does apply here. And I'm really
only thinking of 2, maybe 3 folks. These were the people who managed to be the
most productive members of the team _while_ dealing with all of the manager
BS. When you find one of those you do what you can to stay under them.

------
jefffoster
Whilst I agree that technical leadership is one aspect that skilled engineers
can develop (and I agree that it's important for all engineers) there are many
more.

For example, developers can grow into great product managers. Some can deep-
dive into a topic and develop by sharing that knowledge through conferences,
blogs etc. Some are interested in the people management side of things (scrum,
kanban etc). All of these (and much more) are incredibly valuable and increase
the value to the company they work for.

The challenge for companies is to recognize all these degrees of value (and
reward them appropriately). I did some work to try and capture this with a
visualization called a skills map ([http://blog.red-gate.com/skills-
maps/](http://blog.red-gate.com/skills-maps/)). Any feedback greatly
appreciated!

------
dmfdmf
This is a problem not just for coders but almost any technical area. A loooong
time ago when I was still in engineering I worked for Big Corp, Inc. and they
had a designation for master technical talent, I forget the name, so let's
just call them Jedi Masters. It was a non-management path for those who didn't
want to go the management route but it recognized their value to the company.
If you reached this level you had no manager and had no assigned work but
people from other projects could come to them for advice, help, consultation,
etc. and they could choose what they wanted to work on.

Often the Jedi Masters were tapped to teach intro engineering course to new
engineers on the specifics of the type of projects this company worked on, so
this was a quasi-academic and quasi-consulting gig for the best of the best
engineers.

As a fairly new engineer, I got assigned to a new group and invited to a
meeting that could impact the system I was working on. I show up and it is a
meeting with an engineering partner (outside company) that was contesting some
calcs regarding the pipe strength and mounting requirements for an
installation (multi-billion dollar project). Their engineering team was
insisting on assumptions that would have quadrupled the cost of a system that
our group was responsible for, not to mention weeks or months of delays to
recalc and redesign the system. Unbeknownst to me, this dispute had been at
logger heads for months with no resolution.

One of the Jedi's, let's just call him Fred, taught me years before in the
intro courses and I had remained in contact with him over time. Based on the
courses Fred taught I thought he might have the expertise and interest in this
area to take a look at this problem so I met with him and gave him the
technical details. He agreed to attend the next meeting and advise but he made
me do all the calcs, presentation and etc. for the next meeting but all under
his guidance. So I go through my PPT presentation and at the end the other
company's engineers have all sorts of objections, disagreements, etc. So our
Jedi steps in and starts fielding questions and asks them to justify their
position. It turns out that their reference text they were using to justify
their position was actually written by Fred! I can still hear the other
engineer say, "you mean you are Fred XYZ that wrote book ABC" with awe and
respect in his voice. It turns out they were missing some important exceptions
and qualifications later in the book that Fred cited and the meeting and
conflict was resolved.

So the moral of the story is to always have a Jedi in your corner? No.

The moral of the story is that engineers and problem solvers (and I assume
coders) have different motivation than the "success" of big, showy career
managing a lot of people. We (technical people) love to solve problems and
management is projecting their values onto technical people when they offer
them management positions as "promotions".

~~~
icyfenix
This is exactly the sentiment I was going for - people who want to stay
engineers should be compensated for their badassery, and respected for it,
which is usually all they want. That right there is exactly the "power to say
No" I was talking about. And how do you know if an engineer wants to stay an
engineer or not? By asking them.

~~~
dmfdmf
I don't want to disparage the whole management class but I think part of it is
that manager types don't really get the motivation to solve problems. They
think that if someone doesn't have a manager telling them what to do then they
won't do anything, but that is just psychological projection. Fred was one of
the happiest (and busiest) guys at this company and many strived to achieve
his status.

Regarding respect; After this meeting technical colleagues praised me for
bringing Fred in to get the problem resolved. Manager types praised ME for
resolving the conflict. It was really a big deal and really advanced my career
and Fred was happy to let me get the credit which is why he made me do the
presentation but he got respect from the people "in the know" and that is all
he really cared about.

~~~
curun1r
> They think that if someone doesn't have a manager telling them what to do
> then they won't do anything

As someone who has moved from being an IC to being a manager, I can assure you
that's not true. What we do think is that an engineer won't necessarily work
on the right things. Engineers have a tendency to work on something until
they've solved it, which isn't the same things as finishing it. This is why
personal projects usually end up being unfinished and unpolished. Engineers
also sometimes let the perfect become the enemy of the good. The oft-cited
Malcolm in the Middle episode
([http://www.youtube.com/watch?v=RHpJFROEOmg](http://www.youtube.com/watch?v=RHpJFROEOmg))
illustrates this well.

As a manager, I don't see it as my job to keep my team busy or even
productive...they do that on their own. I see it as my job to keep them
focused, particularly on the tasks that will provide the most benefit for the
business.

~~~
Roboprog
"Focus"

[http://www.technovelgy.com/ct/content.asp?Bnum=1503](http://www.technovelgy.com/ct/content.asp?Bnum=1503)

Courtesy of
[http://en.wikipedia.org/wiki/A_Deepness_in_the_Sky](http://en.wikipedia.org/wiki/A_Deepness_in_the_Sky)

Looking forward to that Vice-Podmaster promotion? :-)

You should note that the phrasing of your concerns probably strikes a certain
amount of dread in some of your underlings.

------
JimboOmega
Am I the only coder who's always wanted to move into the business side
eventually? I go back and forth on if I want to pursue an MBA every couple
years or so (though I doubt the education would be worth it, it'd be a stamp
on my resume for wanting to go that direction).

Working with brilliant people and managing people problems are very complex
and interesting to me.

~~~
patio11
There's quite a bit of variety on "the business side", FWIW. Getting an MBA
does not necessarily get one increased access to it, depending on what you
want to do and where you want to do it.

Dave McClure had a really good discussion once on starting a startup as the
new MBA: far more interesting to hear you talk about how you sold $200k of
sales than hear about how you read about someone doing the same. This also
gives you a lot of opportunities to directly apply engineering skills in the
service of your business goals. Those opportunities exist (in quantity!) in
real life, but may not in any given MBA program.

~~~
jlees
And for the management side, growing an engineering team from 1 to N will
teach you more about people and (early-stage) organizational dynamics than any
number of case studies. However, learning by doing -- and potentially failing
-- doesn't appeal to everyone, and you can certainly balance the "on the job"
learning with book-learning too.

I did an executive MBA, and plan to move into people management at some point.
I enjoy it and I love the feeling of empowering a team to be excellent. At the
same time I feel that you need a solid base as a respected individual
contributor, especially if you are leading the team technically rather than
playing bug-assignment Tetris -- which is what I'm focusing on for now.
Management can seem like a dirty word in engineering, but some of us like
doing it.

------
morgante
A lot of people in this thread are pointing to the possibility of a technical
track, but I just don't buy it.

Any technical track stops far short of the management track, even in the most
enlightened of companies. Taken to an extreme, you don't get to be CEO off the
technical track.

Ultimately, if you want more money and influence, you have to choose the
management track. The technical track just exists to keep technical talent
from leaving——look at any companies with technical tracks (ex. Facebook) and
you won't find their top earners on it.

~~~
tdaltonc
Some people value autonomy and freedom from obligation more than money and
influence.

~~~
morgante
> Some people value autonomy and freedom from obligation more than money and
> influence.

Of course I know & respect that. My point is just that having a "technical
track" does not remove the incentives many engineers see for moving into
management.

------
fein
For me its pretty simple:

Pay me what I'm worth. None of this managerial shite, just dollars. I will be
happy.

~~~
sliverstorm
But what if you are worth more, managing a group of engineers?

Sure, it is a bit of a new skill, but the ace engineer who can guide a team
with his engineering wisdom is way more valuable than the engineer who just
works by himself.

~~~
sheepmullet
That's a false dichotomy.

You can guide a team while "just" being a member of the team. Leadership and
management are not the same skill.

I guess what you are saying sort of makes sense in teams with a high ratio of
junior:senior engineers. But I'd question whether that is a good way to
structure a team if you are working on complex tasks.

------
chuckcode
I really like the idea of "handoffs" that the article discusses It indirectly
brings up what I see as a major problem for some of the most talented
engineers I've worked with which is that some point they get too bogged down
with the incremental features and maintenance on all the amazing stuff they've
done in the past to work on new things. When it would take them a couple days
to implement/fix X but weeks for someone else to come up to speed management
just can't resist assigning it to them and eventually they become burnt out.
Code reviews and mentoring can help this to reduce the time for new folks to
spin up and contribute but I think a formal notion of handoffs is a really
interesting idea.

Having been both an engineer and a manager, yes different tracks for different
people are really helpful. The main thing I've learned is that different
people want different rewards an there is no substitute for spending the time
with people to figure out what sparks joy for them. Usually there is some
baseline of money but often freedom, respect, and cool projects are just as
important.

------
icyfenix
Well yeah on the dollars++ and the equity++ - often that's a harder sell,
existing managers usually have to have some kind of thing to point at in order
to make those things manifest - a lot of non-coders don't know how to quantify
your contributions- these strategies are supposed to add up to raises,
promotions, bonuses, etc., and make getting the tangibles you want easier.
Plus, if the tangibles don't come with the thought leadership recognition,
someone else will usually come along, and recognize you in the way you want to
be recognized.

------
azimuth11
Thanks for this, it helped me think through some very specific things that I
have been struggling with at my startup. I joined out of school as one of the
first engineers excited as hell, but have been somewhat sad/depressed/etc.
over the last few months because I've felt a lack of direction and proper
guidance.

Over lunch, president asks me if I wanted to become an engineering manager or
something of that nature as well as take management coaching classes. It was a
very sad thing to hear someone say to an engineer.

We want to lead by example. Thought, learning, and then code. We want to set
or be a part of an engineering culture that has the freedom to be creative in
our space. Some roles that jump out at are the developer advocate type roles.
Not just "Hey, look at what you can do with our APIs", but be learning and
sharing that knowledge with our peers and others around the web (recruiting).

Maybe it's time for a change.

~~~
redmattred
I'm really curious to learn more about the different directions you're
thinking about and what kind of guidance you wish was there, but you don't
feel you have. For my own startup, I'm trying to dig into the career
challenges and questions developers have and try to build a product that helps
them in their journey.

If you have a moment, shoot me a note at matt@codejobs.io

Also, Drive by Daniel Pink is worth a read if you haven't read it before. It's
main hypothesis is that Autonomy, Mastery, and Purpose are the keys to
happiness in your career.

------
Whitespace
Having just become a co-manager for ~50 engineers, this is really interesting
and timely advice. I don't pretend to have all the answers about how to reward
great engineers, so hearing more people speak about this is really useful to
me.

My initial reaction is "reward them with more things they can say no to" but
that ends up being project management-y if not outright manager-y. I'm very
curious to hear more specific examples where this isn't the case.

If anyone in NYC and is in a similar situation to me, I'd love to meet up for
coffee to share notes. Or in SF, for that matter (I'm here about once a
month). Email in my profile.

------
smenko
Err... Money???

Most people will (rightfully) settle for money. Because people need love, and
to demonstrate love you need to show that you care, that you're willing to
give something up in a hard situation. And the only thing a company cares for
is money. So, I want said company to give me money. More money than the
'manager'. Because I can do their job just as badly as they are doing it, but
they can't do mine at all.

I don't want your stupid titles and shit - those are cheap. Cash is what will
hurt you. Pay up if you care!

And when people realise they have to pay you or lose you, then you get
respect. Priceless!!!

------
jaunkst
Give me equity stake. I don't want to manage, I want to come out of the end
ready to start my own venture or retire and do what I love and build and
awesome open source project to give back to the community.

~~~
ultimape
If money is a means to an end, why not just find an employer who provides and
supports that kind of work directly?

~~~
cookiecaper
Because having the actual money lets you determine the end and implement it by
your own definition.

------
Bahamut
I think the most important thing is to have a conversation with your employees
- ask them what do they want to do, and how do they want their career to
evolve. Constantly keep in sync with your employees' desires, and you should
be fine.

------
gvb
My summary/option: Technical leaders should be front-running the team so that,
when less experienced engineers run into problems, the technical leader knows
in what direction to point the team to find the solution to the problem.

Having technical leaders stuck on legacy Sisyphean tasks (a) sucks up the time
that should be used front-running the team for solutions to future problems
and (b) removes opportunities for less experienced engineers to learn new
ideas and skills, hindering their education and development.

------
atlantic
I worked for a while with a software consultancy, as a .NET consultant. One of
the nicest things about the company what that they had two distinct career
paths for developers - one technical, the other in project management - and
they asked us up front what our preference was, and directed our work
accordingly. I always thought other companies could take a leaf from their
book in this respect.

------
ZenoArrow
Perhaps more companies would benefit research teams, who work on the next
generation of products with less management interference. Being promoted to
the research team could be a useful incentive to keeping talented engineers
around. If they do stick around, the maintenance team could still consult the
research team about the previous system they built.

------
luckydude
It's late so I'm going to screw this up but there are coders and there are
leaders. The leaders think about other people and how to make those other
people be successful. The coders are more about themselves. Which is fine, I'd
just look for people who are trying to make other people be awesome.

------
clueless123
If a sales guy sells 10x, he gets 10x commision.. If a coder produces 10x, pay
him 10x.

What is so hard to understand about that ?

~~~
jaredhansen
The challenge from the business side is to evaluate reliably how to measure
"10x" in this context. While there is widespread agreement that some
programmers are significantly more productive than others (maybe even 10x as
productive), there is much less agreement on how, exactly, such productivity
is measured.

With sales, it's very easy: you count Dollars In The Door. _Maybe_ you also
count something like New Customer Logos Acquired or something like that, but
generally speaking it's just cash. The salesperson brought in new marginal
cash, and you're paying some portion of that back to him/her.

With code, it's hard to know what to measure: lines of code? Features
produced? Ratio of LoC/bugs discovered? Mean time between when a piece of code
is written and when we recognize that it needs to be refactored? It's just a
much messier process.

None of this is to argue against incentive comp for engineers. It's just to
point out that in sales, you're measuring and paying for _output_. Output is
much harder to measure in engineering than it is in sales, and compensation is
fuzzier as a result.

~~~
clueless123
Sales deals can be quite complex to measure as well.. IMHO is just that sales
guys tend to be better negotiators, so they ask to get rewarded properly o go
somewhere else with their skills.

~~~
seanmcdirmid
Programmers go elsewhere to if not compensated appropriately, eventually. It
just takes them a bit longer than sales guys.

------
firebones
Compensation, equity and when those are ultimately satisfactory, autonomy.

------
icedchai
My experience has been that most managers wind up going to meetings all day
and stop contributing technically.

I briefly (a couple years) managed a small team (<5 developers) and it was
torture. Not worth the relatively small increase in $.

How do you reward your skilled coders? Let them do real, interesting work and
not deal with bullshit (this includes all the time wasting "agile" meetings.)

------
vinceguidry
As a coder that's soon to be taking on a management responsibility, I
definitely feel the weight of it, but I'm up for the task of figuring out
leadership. I might well be more suited to it than a lot of engineers would,
but I also think that management and leadership is less hard than it seems and
that engineers would actually be better at it than their superiors if they
would just give themselves a chance.

The trick to it is to realize that it's not, actually, a skill, when you break
it down. It's an opportunity to structure part of the operation of the company
the way you want to structure it. You can take all those ideas you have about
how to run the company better and put them into practice on a small scale. You
do not have to give up engineering, you're just also engineering at a bigger
level than just with machines. You can and should still program, and still
avoid pointless meetings by bringing your laptop to them and working through
them.

You're engineering human systems now too. There's no conflict with the other
machine-type engineering, because the two are intended to work in concert. So
don't create one where it didn't before exist. Humans are easier to engineer
than machines in many ways. You can tell a human to do what you mean, humans
are smart and machines are stupid, a machine will only do what you tell it to
do. You can't tell a machine to exercise judgment or grant them power or
flexibility, they wouldn't know what to do with it. But grant flexibility to a
human and he'll make your job much much easier.

Power necessarily involves freedom and flexibility, if you've an expectation
to meet a responsibility without giving yourself the latitude to meet that
expectation your own way, including the willingness to put your foot down to
ensure your turf is protected, then you are putting yourself through hell.
It's simple, decide what you need to get the job done, then acquire the
resources, then follow through. If the expectation is unreasonable, then
change the expectation. It's not hard, all you have to do is explain to people
that it's unreasonable and offer an alternative. As an engineer, you should
have already learned the skill of dazzling people with techno-babble. As a
manager, they have to take your arguments seriously and compromise with you.
You can't promote someone to management and then proceed to ignore their
opinions. That's the whole point of the promotion.

I go home after eight hours. My boss will put in ten hour days but I won't
volunteer to. I fully expect my new report will go home after eight like I do.
When I wanted to move to flex time I just started coming in later and when my
boss noticed, I just said I was going to choose my hours from here on out. My
boss insulated me from office politics until I was ready to deal with it and I
will extend the same protection to the new guy. I was somewhat worried that
the promotion would come with strings attached. If anything they're more
worried that I'll get cold feet than they are that I won't measure up. So
they've been kissing my ass extra hard lately.

~~~
cookiecaper
Ah, the innocence of the engineer on the cusp of a new management position.

This is more or less what every engineer thinks when they start a "bridge
position". Very few survive, because the reality is that the management world
is much different than the world we engineers are used to, even after we have
a lot of experience as an employed engineer. We think that since we've seen a
lot of bosses come and go and met and talked to a lot of them, we know what
works and what doesn't, etc. It's not like that. Management plays by a whole
different rule book.

When it comes down to it, management is primarily a psychological position.
Soft things matter _much_ more than hard, measurable things. Engineers live in
a meritocracy, even if they think their employer is bad about that. The
numbers and/or code work and have merit, or they don't. Someone is right and
someone is wrong.

Management is the opposite extreme. Your job is to keep your reports happy so
that they do the job the company wants to do them as well as possible. Yes,
some of that involves acquiring resources and removing barriers to
implementation (the part we engineers naturally think of, and have a lot of
ideas about how to improve), but _most_ of it involves making sure that
_everyone_ likes you as far as is possible, and that in cases where something
that makes someone unhappy must be done, the lowest-value person is affected
in the least direct way, such that they don't stay off your side for very
long. When you are a manager, you are really a full-time politician. To be
successful, you must always be campaigning, not on issues that matter or on
the most correct or meritorious position, but on whatever will make you most
liked, as broadly as possible.

When this was me, I didn't anticipate the heaviness of the political aspect. I
thought as long as I was more or less right and proved myself, it would be
fine. I thought that if I fought for righteous causes, the truth would bare
out and we'd all win. What I had to accept is that this is not how the real
world works. I was forced out before my first project even had a chance to
wrap. I don't think I was overtly rude to anyone; the issue is that when
you're a boss, people nitpick and look for things to be offended about. You
have to actively counteract that. If you do something adverse to someone, even
something you think is miniscule, you must do it in the most gentle way
possible and really think about it. If you don't do anything bad but aren't
_as nice_ as some of the other bosses, that will come back to bite you too.

I made a powerful enemy just by politely taking a rain check on a lunch
invitation. I thought that was fine and not a big deal, because everyone knew
we're all really busy and that having lunch is not a major priority for most
people. Turns out, it's not fine.

I made several not-powerful enemies because I didn't regularly pay for
everyone's lunch or bring in donuts, cookies, or some other type of treat,
which a couple of the other guys did. It doesn't matter that nothing in my job
description involved procuring donuts or lunch for everyone. It doesn't matter
that I was very generous in other ways. It doesn't matter that I would rather
spend that half-hour that I would've spent waiting in line at the donut shop
on actual work, like writing a few extra tests or even sitting in a pointless
management-level meeting where nothing got decided. All that mattered was that
some other guys did this thing, and I didn't. I was expecting people to note
these other things and care, but they didn't care because they didn't benefit
directly and personally. I wasn't running a tight campaign. A tight campaign
wouldn't have let any other employee at any level be more popular or more
important.

The problem, of course, was that I didn't go into it to be a politician; I
went into it to build awesome stuff and have authority to see it done the
right way. Once you're a manager, the only thing that you should care about
building anymore is your personal reputation within the ranks. (I've found
this to also be true if you want any room to negotiate as a non-management
employee.) Doesn't matter if it's better for the company long-term. That's not
going to help you. All it means is that they'll still be around to fire you.
What matters is that you're exploiting your position to groom your personality
cult. Nothing else will help you, because most people do not understand
anything else.

One could argue that these are exceptional situations, but I don't really
think they are. Maybe someone else would find some other minor thing to
nitpick, but they'd still do it. _Everything_ you do reflects back on you, and
it's not about merit or correctness anymore. It's about feelings -- feelings
that are completely and utterly unreasonable, as feelings often are. When you
become a manager, you are the steward of feelings. It becomes your job to
ensure everyone on your team is all good feelings and, furthermore, that
_everyone else_ in the whole company is all good feelings too, and it gets
_very_ personal. Most people cannot make a decision based on the merit of
something, they can only make decisions based on appearances.

After trying my hand at this for a while, I decided that I'd much rather stick
to coding. Managers become managers because they don't know what else to do
with themselves. They are forced to live in the ghetto dictated by irrational,
unpredictable human emotion that engineers usually consider something that was
left in junior high. Once you get into pretty much any other field, any field
where empirical thought processes are not a fundamental component of the day-
to-day workload, you realize that ghetto never really got left behind by any
of your non-technical peers; it's the only world they know how to live in.

Good luck man.

~~~
noname123
Just came to say that I really appreciate this comment and an example why I
still read HN despite all of the signal-to-noise of startup hoopla's.

I want to second and say that when I was very young, I had the perspective of
the coder who thought I was being meritocratic when I judged my lead or
project manager by their technical worth, ability to lead, whatever; and
thought what a dumb naive and pandering move my PM would do by bring Dunkin'
Donuts Munchkin's to our morning meeting, but the truth is I judged him
unconsciously for those Munchkin's; and after learning the hard way, I'm
bringing out all of the proverbial Munchkin's of
pandering/cajoling/politicking to everyone at work now.

I'd say for myself that I had once retreated to a purgatory of technical
"proving ground". But it was a false purgatory with empty promises, and I'm
slowly coming back to the harsh reality of the physical pecking order of lunch
tables at junior high cafeteria. But it bothers me less because I realize now
how petty both technical and social people are in their own ways.

------
known
Pay his taxes

------
girldevninja
Great article!

------
icyfenix
Ah sweet, thanks for the share. I hope this helps engineers do things that
make them happy.

