4 ms·
> The fundamental knowledge of math and science that separates engineers from 'coders'. Only math. Furthermore, someone with years of coding instinctively deve
by narribbi 9y ago
> 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.
- quaunaut 9y agoThis 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.
- wutbrodo 9y ago> 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.
- mratzloff 9y agoI 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 9y ago> 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).