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."<p>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.<p>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?<p>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.<p>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.
Some great general advice here, but regarding a specific point:<p>> 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.<p>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.<p>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.<p>As an aside, there's a good GUI/scriptable graphing app for OS X that just had a major update here: <a href="http://plot.micw.eu" rel="nofollow">http://plot.micw.eu</a> It's a bit quirky, but it definitely fills a niche.
> Nothing should ever be just a means to an end<p>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?
<i>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.</i><p>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.<p>I have never used Sublime text but this honestly surprises me.
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.<p>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.<p>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).<p>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 <i>or even whether they are fundamentally competent in the trade</i> just by looking at their credentials.<p>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.<p>> 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.<p>Too often I hear the 'leave the comfort zone' argument. But finally opposite side is also mentioned - panic zone.<p>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.
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.<p>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."<p>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.<p>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.<p>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.<p><a href="https://ieeetv.ieee.org/meet-the-authors/carl-selinger-stuff-you-dont-learn-in-engineering-school" rel="nofollow">https://ieeetv.ieee.org/meet-the-authors/carl-selinger-stuff...</a>
"Learn new tools"<p>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.
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.<p>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.<p>The story of why I came up with this idea is here: <a href="http://ohcanadaanthem.com/story-oh-canada-anthem/" rel="nofollow">http://ohcanadaanthem.com/story-oh-canada-anthem/</a><p>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.<p>I finally took them all down - except the "Oh Canada" website (my home country) which comes in handy for my own use: <a href="http://ohcanadaanthem.com/" rel="nofollow">http://ohcanadaanthem.com/</a>