
Philosophies for Software Engineers - crablar
http://softwareengineeringdaily.com/2016/02/12/10-philosophies-for-developers/
======
vinceguidry
Please don't let things like "Apple makes $1.8MM per employee" get to you. It
leads to stupid decision-making. Yes, the company is making more money on your
efforts than it is paying you. It's called business, you take inputs and add
value to them and sell them to other people who will turn around and do the
same thing. If you had capital to throw into a business venture then you'd do
it too.

I met a guy a few weeks ago who'd moved over from California. He wanted to
learn how to code, and told me his story. He was a business sort who went into
business with a software developer. The dev did good work, and the business
guy managed to get it funded. Just when things started picking up, the dev
decided he wasn't getting enough of the pie and bailed, destroying the entire
enterprise. He wanted to learn how to code so that this wouldn't happen to him
again.

So I'm giving him an hour or so a week to show him how web development works
so that he can code a prototype himself. Then he can get funded and hire
employees rather than deal with the emotional vagaries of software developers.
I don't blame him at all.

Business guys are typically going to make more money than the coders are, it's
pointless to fight this. The better route is to go into business yourself and
capture the value yourself. The reason is that the business side is the human
side, and humans are harder to deal with, ultimately, than computers are.
Also, humans have money and computers do not.

~~~
jasode
_> Apple: $1,865,306 per employee_

Also, that Business Insider article is an inadvertent IQ test for people who
want to regurgitate their figures. That $1.8 million number is _revenue
/#employees_ and not _profit /#employees_. Using profit calculation of
$53B/98k is ~$500k. Since, a fully-loaded FTE in Silicon Valley is ~$250k, the
~$500k doesn't look that insane.

If a writer copy&pastes stuff like that into their own essay without critical
thought, don't be surprised if it taints the rest of his essay. For example,
the " _you are not a commodity_ " is not fully reasoned out. In the essay,
it's just an empty platitude/affirmation instead of explaining _why_ some
programmers are treated as commodities and _how_ to differentiate themselves
to avoid that categorization.

~~~
carboncopy
If you use profit/#employees, then you're double-counting. The employees'
salaries are already taken out of profit. That's why it's not fully
disingenuous to consider revenue instead.

$500k of profit generated per employee sounds excellent, but it's also
omitting other capital costs made by the business. Essentially, none of these
benchmarks can give you the complete picture.

------
dasil003
> _After you have spent enough time in the first tier of the intellectual
> strip mine, we will make you an SDE 2, where you can do slightly higher
> level refactoring for $150k a year, which will make the giant company $5
> million. This is what is called an arbitrage._

I've been a programmer my entire career, and so my interests align with this
ideology, but quite frankly it is offensive to call junior software dev work
an "intellectual strip mine", and to assume a priori that your salary will
return 10-20x multiples in value to the company.

The reality is that it is highly non-trivial to derive economic value from
programming. You have to be able to sell _something_ in significant volumes.
That is the value the company is bringing to the software engineer. How much
value any particular employee brings to the organization is impossible to
calculate. Certainly the engineers will bring efficiencies that are impossible
to get any other way, and perhaps they enable the entire business. But you can
say the same about the sales people, the biz people, the product people; even
the much-maligned marketing people may be essential to keep the revenue
flowing.

There's a huge bias in any industry to overvalue your own work over that of
other disciplines, simply because by definition you know more about it than
what those other departments do. There's something I find really off-putting
about a lot of abstract whining about how underpaid developers are. Sure, some
are underpaid, also some are overpaid NNPPs, but as a whole we are doing way
better than the vast majority of careers in the world right now.

All this is not by way of saying you should be satisfied with what you're
given, but rather that you should pull your head out of the sand and recognize
how the world works: you don't get paid what you _deserve_ , you get paid what
you _negotiate_. And negotiation is a skill you have to learn. If you don't
want to learn anything about business and you just want to write code, then
you should expect to be taken advantage of. If you want to capture more value
you create, the first step is defining that value, and you can't do that
unless you understand the business. From there you can have honest
conversations with your employer on more equal footing, and decide to either
stay or leave. This business knowledge will also enable you to start your own
company with a much greater chance of success than the majority of startups
with purely technical founders who start with a build-it-and-they-will-come
mentality.

~~~
gizi
It probably works like that in the corporate world. But then again, most
corporations today are pretty much like taxi companies waiting for their own
Uber to put them out of business. The company of the future is rather a
platform running on the internet. Any company that looks more like a
collection of politicking corporate offices instead of an internet platform,
is just a dinosaur waiting to get wiped from the face of the earth. The logic
and rationale in things like Uber is totally different than what you have
described. Uber does not "overvalue" the work of its devs. The essence of what
it does, is created by its devs. Furthermore, there are pretty much no other
departments in the business. These other departments are all just automated or
outsourced distractions. They are not supposed to disturb the core business.

~~~
dasil003
What an interesting dichotomy you have painted: internet platform versus
politicking corporate office. This is exactly the kind of myopia I was
referring to where a software engineer thinks everything that is not tech is
bullshit. In fact there is a huge range of ways to succeed in business, and
while all are helped by efficient technology to varying degrees, technology is
not the primary driver of value most of the time. You can bet your career that
Uber leadership is spending every waking minute figuring out how to gain
structural advantages to solidify their position—the tech is easily replicable
and becomes more so every day.

In any case though, you seem to be putting some words in my mouth since I
never said anything about Uber's valuation of its engineering. My point was
much more universal than that and had absolutely nothing to do with the
corporate world or anything else. Employers pay their employees what they feel
they have to. Uber pays them more because they need the best and the market is
very competitive, but there is absolutely no link to the bottom line.

~~~
gizi
> technology is not the primary driver of value most of the time

Most probably. My advice is just that it is a bad idea for a software engineer
to work in an environment where technology is clearly not the primary driver
of value.

> Uber pays them more because they need the best and the market is very
> competitive, but there is absolutely no link to the bottom line.

Without internet platform, there would be no Uber at all.

It would be like saying: "Their warships are not the essence of the Navy. The
Navy wants the best ships, but there is absolutely no link to winning naval
battles."

~~~
dasil003
> _It would be like saying: "Their warships are not the essence of the Navy.
> The Navy wants the best ships, but there is absolutely no link to winning
> naval battles."_

No, it wouldn't be like saying that at all. We are talking about the link
between profits and salaries, not assets and objectives. If you can't
understand that there's nothing more I can really say.

------
MCRed
As an old guy, let me share with you which of these I think was the biggest
lesson for me:

\-- We do not need to be lead by business people.

MY new rule for startups - the big engineer should be the CEO. You can have a
CTO and other engineers. You can have a VP of bizdev or sales. But the big
fish needs to be an engineer if you are a tech company. If you are making
biotech the big fish needs to have biotech engineering. If you are
manufacturing, then the big fish needs to be a manufacturing engineer.

The number one mistake I see startups make (especially when they are started
by younger people) is taking some type-A business school graduate and making
him the CEO.

This is the cause, ultimately, of most of the failures of startups I've
experienced (and I've worked for, founded or worked with a couple dozen.)

Or, as a second order function, type-A business school graduates who have
never started a company or worked a real job but do instead work for a VC
firm, forcing bad decisions on your company.

Most of the fights between founders are because business guys are forcing bad
decisions on the company.

The problem is, business school doesn't teach YOUR business. It teaches
general business concepts. These are not difficult for engineers to master.

IT's impossible for these business guys to master engineering. (Yes, 30 years,
still haven't seen that- the best ones just find an engineer they trust and
get out of the way.)

As an angel investor, if your CEO isn't a geek, I'm not putting my money in.
And if you look at the "successes" where this is the case, it's usually an
arbitrage opportunity (Eg: somewhere just piling a bunch of money behind a
halfway competent business model with half way competent employees is going to
make money because the situation is the result of a structural inefficiency,
usually caused by government: uber for example.)

~~~
louprado
Agreed. The main problem is you can lie and game the VC's. "It's called
future-selling and everyone does it", a biz-guy once told me. It's not a lie,
we are "hacking the interview". Coders like hacking, right ? You see, just
rebrand "lies", muddle the context and now your type-A biz co-founder can say
anything while his engineer co-founder sits their quietly wondering if this
really is normal. I've also heard "I'll stop doing that if it makes you
uncomfortable" but once it is part of a person's personality, it can become
pathological. They don't even know when they are acting this way.

The disconnect comes from engineering environments where there is no Alpha and
Beta mindset, only varying degrees of competence. Trust your instincts and
conscience. The VC only has a limited time for due-diligence.

~~~
nickpsecurity
This is a great article on that which calls it "investor storytime:"

[http://www.theatlantic.com/technology/archive/2014/08/advert...](http://www.theatlantic.com/technology/archive/2014/08/advertising-
is-the-internets-original-sin/376041/)

I still agree with MCRed's points. Just, as you said, have to watch out for
the games people are playing that seem to be working for whatever reason.

Note: There was another link I had about one company getting crazy valuations
where author showed they're basically telling investors what they want to
hear. It broke down the tactics then showed they work too often. Can't find
the link.

------
sjclemmy
"If we aren’t in control, it doesn’t change anything whether or not we assume
that we are in control. But if we are in control, it would be very hazardous
to our well being to assume that we are not in control"

I love the logic of this argument - it has so many applications - think about
applying it to the climate change debate.

~~~
fnovd
[https://en.wikipedia.org/wiki/Pascal%27s_Wager](https://en.wikipedia.org/wiki/Pascal%27s_Wager)

The fallacy here is that there is no downside to belief and that finite losses
spread over infinite scenarios are still finite.

Applied to controlling one's own destiny, the issue is that there is a middle
ground between having no control and having complete control. Obviously it is
a waste to believe you have no control and to do nothing. It is also a waste
to believe you have control of everything: I'm not going to control the
weather or other people's moods, so it is a waste of effort to even attempt to
do so.

The question, then, isn't _if_ we can control our destinies, but _how much_ we
can control. Identifying the areas in which your effort would produce a
desired effect is paramount. Though of course, due to our population size,
you'll always find people who bet it all on black day after day and made that
moonshot due to their unfounded yet devoted belief that the universe would
unfold the way they wanted it to.

------
lorddoig
Outright rejection of the fact that life, including your career path, is in
part chance-based is dangerous. A sizeable chunk of the part that isn't isn't
in your control either, it's controlled by your environment and the people who
populate it. If an asteroid struck, and we were all made redundant, you would
not have 'lost' \- a large example to illustrate a subtle point.

Believing otherwise is the kind of self delusion that leads to mid-life
crises: when the religion of You crumbles and a desperate scramble for a new
faith begins.

Life is, in part, a lottery. Failure is fine. Failure is to be expected. Don't
read in to it in the context of your self worth, but look at it objectively
and see if anything is to be learned. Take risks and accept reality, and never
reject the truth, especially when it's staring you right in the face.

------
fennecfoxen
> Don’t believe the one-size-fits-all interview process with whiteboarding
> problems. These serve to grind away your individuality and make you feel
> like an assembly line worker.

In my experience, the interview process with whiteboarding problem can go one
of two ways. One of them is the "find what we think is the textbook solution
to this toy problem" way. The other is the "communicate to us as you attack
this toy problem so that we can understand your thought processes, problem-
solving approaches, and your experience with these topics" way. Only one of
these is really objectionable.

~~~
MCRed
I think both of them are, because none of the problems are really good for
explaining your thought process. In fact, it is a contradiction to try and
think about a solution to a problem and to give a dissertation on how you're
thinking about the problem. You can do one or the other, and in the latter
case you have to have solved the problem previously.

What I do is ask people about a problem they have solved and get them to teach
me about it. If I learn something then it's a good result.

Asking people to solve a trivial problem AND let you into the inner workings
of their brain-- normally a non-verbal activity- isn't testing their
abilities.

~~~
skybrian
It's not about giving a dissertation. It's about collaborative problem
solving. Granted, the interview is rather artificial and considerably more
stressful, but you use the same skills when talking about how to solve a tough
problem in front of a whiteboard.

------
merb
11\. Make Tests, really. Make automated tests, even if they are slow, make
them. trust me. make them regardless what anybody says or regardless the
project size. the extra time it takes will outweight the time you would need
later.

------
JohnLeTigre
These are not philosophies.

------
generic_user
> 1\. You do not have to prove yourself.

> Software is a new field and nobody knows how to do it. If someone says you
> are unqualified and therefore you must do maintenance work, you should
> question that person. We have an upside down system where the people who are
> paid the least do the crappiest work. They tend to be young and naive.

Software development has been meticulously studied for over 40 years. From
Dejurka, 'Goto's considered harmful' to Parnas, 'On the Criteria To Be Used in
Decomposing Systems into Modules', Design patterns, academic studies, Pair
Programming etc.

> 2\. You are not a commodity.

Your HR department has a list of 'potential hires' to replace any position in
your company at a moments notice. The quickest way to build a bad reputation
is to think you are not replaceable and act accordingly.

> 3\. Software engineering is an art and a science but rarely both at once.

> The planning and design process is an art, but once the requirements are in
> place you can proceed more deterministically.

No matter how brilliant you architecture and plan is there will inevitably be
new requirement or changing requirements that cause you to continuously revise
re-architect and re-write large part of your code base. Both design and
Implementation are a messy evolving process.

> 4\. You are not your job.

If you do not love this then its not for you. Thats true in many professions
and Programming is no different.

> 5\. The world is a distributed system.

I could not parse any overall point to this passage.

> 6\. You are not a lottery ticket.

???

> 7\. Choose action over planning. Talk is cheap and execution is scarce.

> This is why nobody cares about your ideas, they care about seeing your
> prototype. John Mayer said that all he had to do to become successful is
> finish his songs.

Writing a plate of spaghetti code that does some neat thing is not what makes
you an employable dependable developer. Writing clean well documented well
though out efficient code that meets the specifications is what does that.
That take planning and discipline.

> 8\. Software engineering is full of lies and people who will try to take
> advantage of you.

This is a bit psychotic.

> 9\. You are not your credentials nor your past.

You very much are. You do not necessarily have to be an Academic golden boy
but you will be judged by your previous experience and projects.

> 10\. As a software engineer, you can take career risks aggressively because
> your downside is fundamentally capped.

That works out great unless you have to pay 2500$ rent each month or buy food
and clothing for your children etc. Not everyone that writes software is a 19
year old trust fund baby...

~~~
gizi
> Your HR department has a list of 'potential hires' to replace any position
> in your company at a moments notice. The quickest way to build a bad
> reputation is to think you are not replaceable and act accordingly.

Things are probably the other way around. Don't take the job if you think that
you will be easily replaceable. In that case, take another job.

> you will be judged by your previous experience and projects ...

Never apply for a "job". Always apply for a project, or rather, do your own
project, if you can.

What matters, is what the project at hand is all about, and if you have the
ability to do it. Discussing unrelated issues about credentials or unrelated
previous experience, is a sign that the person in front of you has time to
waste; his own time, but also yours. That is a red flag.

~~~
generic_user
> Things are probably the other way around. Don't take the job if you think
> that you will be easily replaceable. In that case, take another job.

So if you apply for a position at Google and they offer you a job that suits
your skill set and background you should not take the job because Google
potentially has a list of thousands of people they could replace you with?
wat?

> Never apply for a "job". Always apply for a project, or rather, do your own
> project, if you can. What matters, is what the project at hand is all about,
> and if you have the ability to do it. Discussing unrelated issues about
> credentials or unrelated previous experience, is a sign that the person in
> front of you has time to waste; his own time, but also yours. That is a red
> flag.

If you apply for a position and the company is not interested in your
experience or previous projects then I'm fairly confident of two things. a)
The company is a sweatshop and burns through junior developers like tissue
paper to flame. b) The work you will be doing will be the worst sort of low
skill crap work that no one with a half way decent resume and experience wants
to do.

~~~
gizi
> So if you apply for a position at Google and they offer you a job that suits
> your skill set and background you should not take the job because Google
> potentially has a list of thousands of people they could replace you with?
> wat?

Yes, exactly. If it is trivially easy to find thousands of people with your
skill set and background, there is something wrong with that skill set and
background. You will need to work on it, because these things are an accident
waiting to happen.

> a) The company is a sweatshop and burns through junior developers like
> tissue paper to flame.

Not really. They have a real problem and they cannot readily find someone to
solve it. And then you come along. Now the problem may finally get solved.
This is how it best works. If not, there is something wrong with the entire
situation.

> b) The work you will be doing will be the worst sort of low skill crap work
> that no one with a half way decent resume and experience wants to do.

If you do not have a pretty much unique selling proposition, you will indeed
compete at the bottom of the market. You need the ability to solve a
particular type of non-trivial problems and you must preferably have been
specializing for years in doing that. People in your field understand what the
value proposition is, and there is no need to endlessly debate this with them
first.

Google do not use the technology in which I specialize. One day they may, but
at the moment, they don't. So, I would never run into them, when occasionally
looking for a project (once every 3 - 5 years). The day that Google starts
using this technology, they could indeed try to ask me for an interview, but
why would I prefer them to the established players? Am I replaceable? Yes, but
Google are even more replaceable. I will have done fine for years, before they
decided to enter the field too. Who exactly is the one that is replaceable
here?

