
Things I learned as an engineer that I wish I had known in grad school - maebert
https://medium.com/@maebert/9-things-i-learned-as-a-software-engineer-c2c9f76c9266
======
Agathos
I definitely learned 1, 3, and 5 while in grad school and I'm a little
surprised he didn't. On 1 especially, I will tell people about grad school,
"Being smart can only get you IN. Persistence and hard work get you out."

4 is interesting. I was THE stakeholder in my thesis project, being literally
the world's leading expert on that very narrow field and being the one who
would benefit or suffer the most after its success or failure. Now I'm working
in the software industry and I have a lot less autonomy and responsibility.

------
peterwwillis
It's useful to note the difference between enabling your customers to use your
product and supporting the company's goals. Enabling your customers to use
your product means your company is fulfilling its purpose, and invariably this
will be a good thing. But there's more to a company than just serving the
customer. There's the people who work at the company and the work they do that
matters too.

This is what's so funny about #2 and #5: they are at odds. If you take pride
in your craft, you can't possibly feel good about 'just shipping' something
out the door. The phrase 'just ship' is literally saying you're giving up
caring about anything else to only focus on delivering a product. Where's the
pride in your work? Where's the respect given to the other employees who have
to deal with your output?

There is a time and a place for 'just ship', but it should never be a
constant. If you'd like to reduce the costs of the company (by not having to
spend as much time/money on maintaining 'just shipped' products), and help
your co-workers feel better about the work being done, try to focus on the
design and implementation more and produce something of real value.

------
nadam
I agree with most of the observations, although I think that 1. and 8.
contradict each other a bit.

In my opinion leaving your comfort zone often, so becoming kind of a
'generalist' is a good strategy only if you can learn subjects quite deeply
quite quickly, which needs some kind of raw intelligence. Among the successful
scientists/engineers only the the extremely intelligent could be successful in
relatively different topics in my opinion.

~~~
logicchains
I'd say it's more 'preference for learning' than just raw intelligence. Like
with the whole 10,000 hours thing; if person A spends 5 hours a day studying
while person B spends those same 5 hours (watching TV|gaming|socialising with
friends and family), then in a couple of years person A will know a hellova
lot more stuff than person B, regardless of intelligence.

------
Osmium
Some great general advice here, but regarding a specific point:

> An illustration software: I personally prefer Inkscape, but the industry
> standard Adobe Illustrator or newcomer Sketch are just as good. Use it to
> post-process your plots and graphs; it’s often much easier than writing
> plotting directives in Matlab or matplotlib.

This is something I've been grappling with for a while. It's true that
plotting directives are an awful pain, especially when hopping between
different graphing options for different specific problems, but on the other
hand they do make re-producing the graph when you have new data wonderfully
straight-forward. I still don't know what the best workflow is here.

The best candidate seemed to be Sweave+ggplot, but it's very slow to produce
complicated graphs, and certain kinds of data manipulation in R aren't as easy
as in Matplotlib/SciPy, so I'm going back to IPython notebooks now. But I
really haven't found a great solution.

As an aside, there's a good GUI/scriptable graphing app for OS X that just had
a major update here: [http://plot.micw.eu](http://plot.micw.eu) It's a bit
quirky, but it definitely fills a niche.

------
uhmmmm
> Nothing should ever be just a means to an end

What if your passion is not something that pays money? You need money to live,
why can't a job just be a means to an end?

~~~
VLM
In context of the article, take pride in what you're doing. Last night as my
decompression or relaxation tool I was cutting up some nice solid oak trim
pieces for a carpentry project and took enormous pride in getting everything
to fit perfectly with absolutely perfect miter cuts (which is harder to do
than non carpenters think...) Well maybe not utterly perfect but better than
I've ever done before, might not be able to slip a business card in anywhere
but a razor could be hammered into some of the gaps.

Anyway in article context I followed rule #2 in having great pride in doing an
excellent job, I just happened to be doing carpentry for fun at the time. Was
not being an evil programmer by not being attached to a keyboard for those two
hours.

The TLDR of the whole article seems to be if you develop discipline then when
you need discipline you'll be better off than undisciplined folks. Or if you
train hard all the time, work becomes easy, which is crucial during rough
times.

------
001sky
_Intelligence is certainly still a door-opener. But it will never get the job
done on its own. Diligence, rigour, a reliable network, and finally not being
a dick are essential qualities of not just software engineering but any
profession that’s outside the little bubble called grad school._

Aha--Nicely put. The dynamics of premature optimization by gatekeeping
functions is always a good topic of debate.

------
psibi
>> Sublime Text is a great editor with a much higher learning curve than VIM
or Emacs.

I have never used Sublime text but this honestly surprises me.

~~~
lostcolony
I am 95% sure the author meant lower learning curve.

~~~
Already__Taken
I'd call the ratio of things you can accomplish against the amount of things
to learn goes up way quicker with sublime. Vim just plateaus higher.

To be productive you want a steep learning curve.

------
InclinedPlane
I find it fascinating that we've slipped into a world where we have completely
forgotten that liberal arts universities are not and have never been trade
schools. If you want to learn the basics of chemistry, you can learn that at a
university. But as a rule they will not teach you tradecraft, you will not
learn techniques specific to the manufacture of industrial quantities of
chemical compounds, those you will need to learn on the job.

But when it comes to software engineering the gulf is even more severe and
important. Firstly, computer science theory is extremely rarely applicable to
software development, and is far less a suitable foundation for a typical
career in industry than typical science degrees are. Secondly, the highly
specialized knowledge and skills necessary to become even just a basically
competent software developer are sufficiently large and requiring of expert
instruction as to be comparable to many professional trades.

But there are a few problems here. For one it's just not practical for
employers to attempt to use on the job training to force feed new hires that
knowledge, as it would require education in lieu of productive work to the
tune of maybe 2 entire developer-years, give or take. For another, it's also
not practical to try to back feed a trade-school education into typical CS
degree programs. For yet another, most attempts at trade-school software
development educations are huge failures. Partly because almost no one with
enough smarts and talent to actually become a good developer would attend a
trade school, and partly because there's no agreed upon objective standard
curriculum for development as a trade. Currently the best way to learn is
through apprenticeship (decidedly hit or miss) or autodidactism (currently the
most prominent method).

Of course another side effect of this is that because the most important
education a developer receives is a subjective, informal, mostly undocumented
one it is almost impossible to tell how good a developer _or even whether they
are fundamentally competent in the trade_ just by looking at their
credentials.

For various reasons these conditions will continue to prevail for some time.
Personally my bet is that humans will be living on Mars before these things
are sorted out, but I could be wrong.

------
alandarev
> 8\. Leave your comfort zone.

> Of course, there’s also the point where you’re just overwhelmed. That’s the
> panic zone. That’s where you’ll black out. That’s where all you can do is to
> try to keep your head outside the water hope somebody will safe you.

Too often I hear the 'leave the comfort zone' argument. But finally opposite
side is also mentioned - panic zone.

As of recently leaving comfort zone I was completely lost, damaging my self-
confidence. Afterall, I might have walked too far, into panic-zone. Shall take
one step back and try again.

~~~
collyw
I have had a couple of maintenance programming jobs, where there was a
mountain of undocumented code. I would just stare for days, thinking I wasn’t
getting anywhere, but it did eventually click.

------
dkarapetyan
It's always really cool to see how academics approach problem solving whether
it is in software engineering or otherwise. For some reason they are always
approaching the problem and solving it on a higher level whereas most software
engineers are perfectly content hacking away until the square peg fits in the
round hole with total disregard for any higher level principles and
abstractions.

Really good pointers by the way especially the one about not selling your soul
and approaching your discipline like it is a craft.

------
dalek2point3
"An illustration software: I personally prefer Inkscape, but the industry
standard Adobe Illustrator or newcomer Sketch are just as good. Use it to
post-process your plots and graphs; it’s often much easier than writing
plotting directives in Matlab or matplotlib."

Is this good advice? We generate a TON of graphs and charts in academia, and
treating them like "design" objects seems to be a lot of work. Worth it? What
is industry standard practice for good looking data viz?

------
subir
Gem of an article! Echoes several thoughts and notions I have acquired over
the years, the hard way. Here's hoping it reaches grad students, young
researchers and the like.

------
mentos
Great advice. It was implicit but I was hoping he'd point out explicitly how
#6 '80/20 rule' implies #5 'Shipping it'. Its better to get to an audience
quicker with something rough and evolve it from there than to try to bake
something to 100% perfection which without feedback is impossible.

Also I think "Talent Is Overrated" by Geoffrey Colvin makes similar points and
definitely recommend reading it.

------
nichochar
As an engineer just graduating from a good french school, I identified a lot
with the messages here.

Very good ideas, very clearly explained, thanks to the author.

------
jnazario
related is this book by Carl Selinger, "Stuff you Don't Learn in Engineering
School". while i didn't attend engineering school, these are things i didn't
learn until after grad school, things that will get you far in life and work.

[https://ieeetv.ieee.org/meet-the-authors/carl-selinger-
stuff...](https://ieeetv.ieee.org/meet-the-authors/carl-selinger-stuff-you-
dont-learn-in-engineering-school)

------
cliveowen
"Learn new tools"

I disagree with all this part. The way things are going, being a jack of all
trades will only make you irrelevant very quickly. The market needs experts,
and being an expert means focusing on one thing and one thing only. You should
only learn new tools if they're relevant in your field of expertise and if
they're widespread or there's a good chance they might be in the future.
Otherwise, you're just wasting time.

~~~
amirmc
Learning how to learn is also a valuable (meta)skill. It doesn't mean you have
to become a jack of all trades but does allow you the opportunity to reinvent
yourself if the need or desire arises.

------
contextual
I agree with taking on pet projects that have no immediate payoff. And they
don't need to be complicated either, only intellectually stimulating or
ambitious.

For example, a few summers ago I decided to make a web page for each and every
national anthem in the world. A huge website network of national anthems, and
later I would add audio.

The story of why I came up with this idea is here:
[http://ohcanadaanthem.com/story-oh-canada-
anthem/](http://ohcanadaanthem.com/story-oh-canada-anthem/)

I only managed to do 5-6 anthem pages (Great Britain, USSR, Canada, a few
others) before I became completely preoccupied with trying to secure the Star
Spangled Banner lyric site. The site was being hacked constantly.

I finally took them all down - except the "Oh Canada" website (my home
country) which comes in handy for my own use:
[http://ohcanadaanthem.com/](http://ohcanadaanthem.com/)

------
sebnukem2
The "80/20 Rule" is the Pareto principle.

