Things I learned as an engineer that I wish I had known in grad school | Hacker News Reader

Things I learned as an engineer that I wish I had known in grad school

medium.com

131 pointsmaebert37 comments

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.

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.

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.

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.

It depends on your goals.

If you want to be a Python specialist, for example, working at a job where you do exclusively Python and you get paid more and more as you gain expertise, then your time is probably better spent learning Python and not branching out.

If you're more of a "full-stack" developer, you might continue to learn new languages and paradigms, understanding the underlying concepts but maybe never learning language-specific fringe cases. Someone who does this might enjoy learning, and might prefer to switch things up and change jobs every few years.

If you want to start your own company, you'll probably want to be even more of a generalist, not focusing on development entirely. You might have a bit of a specialty in one area (software development or sales), but you'll want to know enough about all areas of running a business to be able to understand what's going on -- but you might want to hire the experts to know and learn more about any one of the areas than you do.

"only the the extremely intelligent could be successful in relatively different topics"

I'd disagree based on experience, not that I'm a successful generalist idiot (although I might be) but its extremely well known in the field, that learning your 8th language or 4th paradigm or 1000th fad or whatever is about 10x easier than learning your 2nd.

Learning one language is hard, but it scales back rapidly. How many different glyphs and syntax and formatting style can possibly exist to describe recursion, or addition, anyway?

Experience compounds.

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 It's a bit quirky, but it definitely fills a niche.

> 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?

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.

This is how lucky people talk. I'm more successful than people I know that are more talented. I could come up with a philosophy on life but I know better.

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.

>> 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.

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

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.

It's been edited and now says:

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

For what it's worth, the learning curve is plotted as learning vs experience. A steeper curve is actually the more rapidly learned one. The concept has been butchered in colloquial speech. ;)

I always assumed it was productivity vs learning. But regardless, yeah, idiomatically we think of it less as a graphing curve, I think, and more of a physical one you have to get over, and climbing steep hills is hard.

He is wrong. Even if you include learning how to code in Python.

You're so fucking right. I still like vim though.

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.

> 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.

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.

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.

"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?

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.

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.

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.

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...

"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.

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.

I think there should be a middle ground there. You can know a lot about code optimization but if you don't have an OK understanding of the lower parts, you will spend lots of hours discussing with sysadmins or netadmins about how it is their or your fault that you application is not behaving harmoniously with the OS, for example.

Being a jack of all trades is not a bad thing most of the times. It helps give you a better understanding in the end.

Breath and depth everytime. Being am expert can open the door and give your words weight, but you need to be able to talk to, relate to, and understand people in other fields. You also need to be able to adapt to change and to borrow concepts from other fields.

What the market wants ("Swift developers with ten years' experience"), what we as labor want ("Fun projects and a paycheck for whatever we make"), and what's actually required ("Wordpress ecommerce theme that's mobile friendly and doesn't look like complete ass") are all different.

The specific demand is invariably for a particular technology or platform, because management wants to solve their pain point right now and want to manage risk. The problem is that those experts are not super useful in five years when the platform changes (or three years, or six months).

Better to be an expert as using different technologies and getting up to speed quickly.

I disagree.

Yes, I still see some job postings that list "8+ years with (niche technology or framework)" (I say niche because asking for 8+ years with something like Java or Ruby isn't exclusionary to generalists, it just means you've predominantly focused on a single ecosystem), but far more often I see "X preferred" "Some exposure to X, Y, Z, or similar preferred", etc. You still want to have deep understanding of a few key technologies, sure, but there's risk hitching yourself too closely to a given tech while excluding everything else that's out there.

A wise man in my company asks younger ones to follow shape of "T" when it comes to skills. Get as much breadth as you can but do ensure that you are deep in one area.

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/

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/

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

Reply on news.ycombinator.com