[narribbi]

> The fundamental knowledge of math and science that separates engineers from 'coders'.

Only math. Furthermore, someone with years of coding instinctively develops such mathematical understanding, while the very same understanding will be lost on someone who just graduated, but has never coded.

[wutbrodo]

> Furthermore, someone with years of coding instinctively develops such mathematical understanding

FWIW, this isn't my experience. I have a CS/math background, spent the first few yrs of my career at Google, and then moved to a startup as the first employee. We had a lot of difficulty sourcing good candidates, and our first two hires were 1) a guy with no engineering experience and domain knowledge that had programmed during his Master's (and had some useful domain knowledge) and 2) an engineer with ten years of experience. I supported the first guy's hire and the second guy was hired against my recommendation.

The first guy hasn't yet had occasion to put his actual specialty to use, and yet after a month of some pretty hands-on guidance to teach him basic engineering habits, he is pretty much crushing it. He's dependable, he's creative, he's hardworking, he can implement stuff quickly but also think about the big picture: he's certainly exceeded even the fairly high expectations that I had of him despite having no eng experience and relatively limited programming experience. I had the exact same experience with a math PhD who worked under me at Google: he was hopelessly unproductive for the first month or two (Google is really, really, REALLY shitty at ensuring that new hires with potential get the guidance they need). I noticed this and took him under my wing to teach him the basics of engineering (which are truly not very difficult to learn) and in a month or two he was one of the best engineers on our team.

Our other hire is.....the opposite of all of that. He's basically been reduced to the only thing he's shown himself able to handle: he spends two days working on okay-to-have changes on the margin that no one really needs but that I could've taken care of in half an hour. 90% of the time he ends up breaking stuff that I have to spend 20 minutes fixing anyway.

TL;DR: my experience has been that there are certain skills and ways of thinking (and perhaps innate talent? I dunno) that are incredibly useful for engineering that some people go years and years and years in industry without ever acquiring or strengthening. On the flipside, someone with these capabilities can become a solid engineer in very little time. Good CS and math depts tend to instill or select for pretty much exactly this set of skills, in my experience. The main gap they have is a set of best practices for being a little more meticulous about their code, and this is shockingly easy to teach.

[narribbi]

There's provability ("math"), and testability / falsifiability ("science"), and then there's just making it work amidst a deluge of trade-offs ("engineering"). If in the end, you simply can't make it work, the entire exercise becomes futile. In that sense, I do not really believe in favouring the formalisms of provability and testability at just any cost. If the person can actually solve the practical problem, then that should allow us to move on, no? That is why I like having that kind of people on my team.

[mratzloff]

I would invite you to consider the possibility that you are coming into a situation with a pro-academia bias that creates the reality you find yourself in. That's not at all unusual for someone who's worked at Google. As long as we're trading anecdotes, I have some that could easily show the opposite.

In my experience, intellectual curiosity, intellectual openness, raw intelligence, initiative, and attitude are much better indicators of success as a programmer than having a degree.

[wutbrodo]

> I would invite you to consider the possibility that you are coming into a situation with a pro-academia bias that creates the reality you find yourself in. That's not at all unusual for someone who's worked at Google.

That's a very good point and I have actually been very careful to consider that. There's still a tiny chance that it's possible, but I'm pretty sure that's not the case. The fact that we ended up hiring this other guy against my wishes gives me a nice little counter to confirmation bias. He's pretty horrible even on the stuff where he has a huge (theoretical) advantage over me and the other engineer, due to having much more real-world experience with it. You just can't work around a lack of creativity, conscientiousness, and problem-solving skills.

For example, I set up most of our non-core-logic systems stuff by the seat of my pants (servers, DBs, caches, etc etc etc). I got roughly zero experience with this stuff at Google because the tooling was so excellent and taken care of by large, expert teams. It's been a great learning experience both in terms of familiarity with the tools and the trade-offs that come with small size/too much to do. Learning these skills is part of why I wanted to try a small company. Since this guy has proven himself utterly useless at anything even remotely involving engineering, he's been reduced to marginal changes to this kind of systems stuff, setting up things that are very low-priority so far. He still manages to mess up most of these! Every time he pushes a config change, or sets up a new service, or does _anything_, something is broken and I need to fix it. Most recently, he burned through a few thousand dollars in a couple weeks by making an entirely unnecessary switch away from our key-value store without noticing that his new set up used a dozen beefy reserved instances.

I don't have 100% confidence in my view here since my sample is so small, but the original point I was arguing against was that "years of coding will teach you mathematical understanding" and that this obviates a math degree. Everything I've seen from different vantage points has pointed to this not being true. It's entirely possible for someone with a decade of engineering experience to be almost utterly useless (cf Jeff Atwood's old post about "senior engineers" being unable to FizzBuzz).

[RealityNow]

What are these basic engineering habits, and why was engineer #2 not able to adopt them?

[dba7dba]

My uneducated guess is that the engineer with 10 years of experience is just very complacent. He probably can get another job even after this one, because of the 'experience', and he knows this.

But the 1st engineer is starting out so he's extra motivated. Motivation brings out creativity, energy, and result.

[wutbrodo]

That doesn't really comport with what I see day-to-day. This guy definitely doesn't enjoy not being able to do anything and breaking everything that he touches; you can see that it upsets him. I don't know why HN (and people in general) are so desperate to avoid the possibility that differences in ability can exist.

[dba7dba]

I agree with you. Some people are just better than others. I don't deny that. I didn't know that the guy definitely does not enjoy breaking things.

[wutbrodo]

> What are these basic engineering habits

IME, a lot of them boil down to the principle of least surprise and not keeping silent dependencies on things in unexpected ways. These sound trivial and obvious, but they manifest in a thousand different ways, and the habit of constantly and subconsciously checking for these things in the back of your mind while designing/coding/reading code is something that comes with practice. As I said, I don't think it's very difficult for intelligent people to learn this give a little bit of time, which is why I hire for creativity and problem-solving skills instead of direct experience with certain tools. Particularly at our current size, dead weight is infinitely costlier than it would be to a behemoth like Google. Our latest hire has never worked in anything but C and he's already more productive on our Python codebase than hire #2, who has the advantage of years of Python experience and months more tenure at this company.

> why was engineer #2 not able to adopt them?

It's not so much that engineer #2 couldn't adopt these habits: it's that he's apparently not capable of doing any actual functional implementation, which is a prerequisite for a functional implementation that's well-engineered. The point I was making was that an intelligent, creative hire missing engineering experience can easily and quickly be taught. But an experienced engineer without creativity and intelligence is not very useful.

As far as why he can't do any functional work: Every time I mention this to someone[1], people seem pretty put off, but I honestly just think he's just not a very smart guy. For some reason, the very idea of differing levels of intelligence seems to offend people, but I'm racking my brains here and I can't think of another reason why he would be so abysmally unable to do anything. In conversation with him, your response never gets addressed and he just rephrases his last point ad nauseum with no hint of comprehension. My (semi-technical) founder has pretty much been working directly with him and he hasn't had any luck in finding things for him to do either. I guess the silver lining here is that I'm batting 1000 on hiring recommendations so I hope in the future I won't be overruled on tech hiring.

[1] Not at work: that would be entirely inappropriate. I mean to friends/confidantes when they ask me how the new job is going etc.

[quaunaut]

This has been my experience. Frankly, coding made it easier to understand the math, and absolutely none of it was complicated when I did finally get to it.