Effective Engineer – Notes(gist.github.com)
gist.github.com
Effective Engineer – Notes
https://gist.github.com/rondy/af1dee1d28c02e9a225ae55da2674a6f
235 comments
For every person who rode a powerful technology wave, there are also many others who rode the wrong ones.
One of my favorite stories from Drew was that when he first started Dropbox, he created a 4-minute demo video showcasing the product that functioned as an MVP for the product. The video drove hundreds of thousands of people to their site and grew their beta mailing list from 5,000 to 75,000 people overnight.
On the outside looking in, skeptics might have thought that it was nothing new. But the MVP provided validation around what future customers actually thought.
My main takeaway from that story (and that I share in the book) has always been to validate your ideas early and often, so that you can get more signal on whether the assumptions you're using to shape your behavior are accurate.
More about the Dropbox story here: https://techcrunch.com/2011/10/19/dropbox-minimal-viable-pro...
One of my favorite stories from Drew was that when he first started Dropbox, he created a 4-minute demo video showcasing the product that functioned as an MVP for the product. The video drove hundreds of thousands of people to their site and grew their beta mailing list from 5,000 to 75,000 people overnight.
On the outside looking in, skeptics might have thought that it was nothing new. But the MVP provided validation around what future customers actually thought.
My main takeaway from that story (and that I share in the book) has always been to validate your ideas early and often, so that you can get more signal on whether the assumptions you're using to shape your behavior are accurate.
More about the Dropbox story here: https://techcrunch.com/2011/10/19/dropbox-minimal-viable-pro...
It's definitely a gamble. When the Apple Newton came up I thought pen computing would be the future, threw everything into it and was at the forefront for a few years. But by 2000 or earlier it was pretty clear that I had bet on the wrong horse. I guess my lesson is to jump ship sooner but then you also often hear that perseverance is the key. Tough equation. Now my belief is that you have to be persistent but also need a lot of luck to be at the right place at the right time.
The Apple Newton was clearly what happened when Jobs had the idea for the iPad 20 years before the technology could actually deliver a usable experience for it. And even then you can see sketches of it all the way back to the 60s: https://books.google.co.uk/books?id=CEc1OOGmA5IC&pg=PA91&lpg...
Jobs had nothing to do with the Newton and killed it when he came back to Apple.
That's true and part of the challenge. It's not always clear what's a powerful technology wave and what's the wrong one.
I've actually got a bit more of a personal connection to DropBox - Drew was active on HN before founding it, he posted it here before posting it on Digg [1], and he took me out to lunch right after they'd gotten their Sequoia seed round and asked if he could convince me to be employee #2. At the time, I was working on a casual game creation startup with a friend, and I declined, #1 because I felt I couldn't leave my cofounder and #2 because Drew had a startup, I had a startup, and at the time it wasn't clear which of us was actually more likely to be successful.
Before you laugh, consider the environment in Feb 2008 (when this occurred). My cofounder was a consultant at Monitor Group, where he'd been researching the casual gaming space and had run across multiple reports saying it would be a $200M, $1B, etc. space (market research reports never agree on market size, because they're largely bullshit). Kongregate had just raised a Series A from Reid Hoffman, Jeff Bezos, and other luminaries. Max Levchin had just raised $50M for Slide the month before. Zynga had just been founded but Farmville hadn't come out yet. The Web 2.0 bubble was in full swing, AJAX and Javascript were the new hot buzzwords (I had just ported Arc - PG's pet programming language, which HN is written in - to Javascript, which is what caught Drew's interest in the first place), and as you can see from the first comment on DropBox's "Show HN", anything that required installation of software was considered a non-starter. And our product concept let everyone, from teenagers to retirees, build their own games instead of being at the mercy of a studio & professional developers.
My lesson from how things evolved - learned much later, and I'm probably still grasping the implications - was to preference personal experience over industry zeitgeist and prestigious research reports. Drew's personal experience with the problem domain and his 75,000 beta signups were worth a lot more than the famous people and industry market research reports around the problem domain we were solving. And this insight has actually saved me a lot of time & aggrevation chasing fads that people realize are bad ideas 4 years in.
But this is not obvious to someone just starting their career, probably because they don't actually have all that much personal experience to draw upon, and because it takes a certain amount of chutzpah to hear about all these eminent people saying "This will be the next hot thing, you better get in now!" and think to yourself "Actually, sounds like bullshit to me." Personal experience is also inherently limited because you've only got your own and it takes years to build; it turns out that the set of problems you can viably solve is actually quite small.
[1] https://news.ycombinator.com/item?id=8863
I've actually got a bit more of a personal connection to DropBox - Drew was active on HN before founding it, he posted it here before posting it on Digg [1], and he took me out to lunch right after they'd gotten their Sequoia seed round and asked if he could convince me to be employee #2. At the time, I was working on a casual game creation startup with a friend, and I declined, #1 because I felt I couldn't leave my cofounder and #2 because Drew had a startup, I had a startup, and at the time it wasn't clear which of us was actually more likely to be successful.
Before you laugh, consider the environment in Feb 2008 (when this occurred). My cofounder was a consultant at Monitor Group, where he'd been researching the casual gaming space and had run across multiple reports saying it would be a $200M, $1B, etc. space (market research reports never agree on market size, because they're largely bullshit). Kongregate had just raised a Series A from Reid Hoffman, Jeff Bezos, and other luminaries. Max Levchin had just raised $50M for Slide the month before. Zynga had just been founded but Farmville hadn't come out yet. The Web 2.0 bubble was in full swing, AJAX and Javascript were the new hot buzzwords (I had just ported Arc - PG's pet programming language, which HN is written in - to Javascript, which is what caught Drew's interest in the first place), and as you can see from the first comment on DropBox's "Show HN", anything that required installation of software was considered a non-starter. And our product concept let everyone, from teenagers to retirees, build their own games instead of being at the mercy of a studio & professional developers.
My lesson from how things evolved - learned much later, and I'm probably still grasping the implications - was to preference personal experience over industry zeitgeist and prestigious research reports. Drew's personal experience with the problem domain and his 75,000 beta signups were worth a lot more than the famous people and industry market research reports around the problem domain we were solving. And this insight has actually saved me a lot of time & aggrevation chasing fads that people realize are bad ideas 4 years in.
But this is not obvious to someone just starting their career, probably because they don't actually have all that much personal experience to draw upon, and because it takes a certain amount of chutzpah to hear about all these eminent people saying "This will be the next hot thing, you better get in now!" and think to yourself "Actually, sounds like bullshit to me." Personal experience is also inherently limited because you've only got your own and it takes years to build; it turns out that the set of problems you can viably solve is actually quite small.
[1] https://news.ycombinator.com/item?id=8863
Wow, that is an amazing story. Thanks for sharing.
It really hammers home how hard it is to disentangle good & bad advice and how easy it is for an outsider looking into to really underestimate the depth of someone else's expertise in a given domain.
It really hammers home how hard it is to disentangle good & bad advice and how easy it is for an outsider looking into to really underestimate the depth of someone else's expertise in a given domain.
>It really hammers home how hard it is to disentangle good & bad advice and
> how easy it is for an outsider looking into to really underestimate the depth of someone else's expertise in a given domain.
> how easy it is for an outsider looking into to really underestimate the depth of someone else's expertise in a given domain.
Wow awesome - I love this comment in particular:
“For a Linux user, you can already build such a system yourself quite trivially by getting an FTP account, mounting it locally with curlftpfs, and then using SVN or CVS on the mounted filesystem. From Windows or Mac, this FTP account could be accessed through built-in software.” CVS!!!
“For a Linux user, you can already build such a system yourself quite trivially by getting an FTP account, mounting it locally with curlftpfs, and then using SVN or CVS on the mounted filesystem. From Windows or Mac, this FTP account could be accessed through built-in software.” CVS!!!
This is by far my favorite HN comment of all times.
I learned a similar lesson when I was working on a product around two years back. I used to extrapolate current trends and predict why my idea could be important in the future. While those predictions sounded good in theory, in reality, it was just me trying to paint my assumptions as facts. None of what I predicted happened.
When you are working on any idea, there's a temptation to be a visionary about your product's impact. But nothing good comes out of this feel-good bullshit. It's better to focus on solving meaningful problems that exist today, rather than being hopeful that they will become relevant tomorrow.
When you are working on any idea, there's a temptation to be a visionary about your product's impact. But nothing good comes out of this feel-good bullshit. It's better to focus on solving meaningful problems that exist today, rather than being hopeful that they will become relevant tomorrow.
> it takes a certain amount of chutzpah to hear about all these eminent people saying "This will be the next hot thing, you better get in now!"
Really? If you don't have that filter you'll be prey for every investment scam that comes along.
Really? If you don't have that filter you'll be prey for every investment scam that comes along.
Many people are.
> takes a certain amount of chutzpah to hear about all these eminent people saying "This will be the next hot thing, you better get in now!" and think to yourself "Actually, sounds like bullshit to me."
More of a personality thing. If you would pitch Dropbox or Facebook to me today, I would consider it bullshit just like back then. Nice little niche maybe but certainly no Unicorns. Who would put sensitive personal information into the cloud?! Obviously not much of a market.
More of a personality thing. If you would pitch Dropbox or Facebook to me today, I would consider it bullshit just like back then. Nice little niche maybe but certainly no Unicorns. Who would put sensitive personal information into the cloud?! Obviously not much of a market.
> there are also many others who rode the wrong ones.
My buddy wrote a book on VRML.
My buddy wrote a book on VRML.
"useless and unlikely to work" -/-> wrong
But without the benefit of hindsight, how do you tell the difference?
When I look at some of the giant wins of the last major tech wave, often times the key factors in their success were external events that happened after the formation of the company. AirBnB benefitted massively from the housing bubble & financial crisis (3 years after formation), which created a large class of people who were desperate for income and whose primary residence was their primary income-producing asset. Uber had to try the idea multiple times before cell phone batteries became good enough to run navigation continuously in the car (2 years after formation), and took off because of the publicity of getting sued by San Francisco. WhatsApp took off after the addition of push notifications to iOS (~18 months after formation) made it feasible to use as a messenger rather than just a status update.
All of these companies certainly did things to influence their success, in particular having a product on the market at the time the market changed to take advantage of the product. But for most of them the product was actually wrong in the sense that it was a complete failure in the market until that market changed. Brian Chesky's fond of calling AirBnB "the worst startup idea that actually worked".
It's like the formula for success = preparedness + luck. This cribsheet does a good job at preparedness, but you have to acknowledge the role of luck if you want to actually capitalize on that preparedness, and being afraid to work on the wrong ideas will often shut you out of ideas that require some luck to work.
When I look at some of the giant wins of the last major tech wave, often times the key factors in their success were external events that happened after the formation of the company. AirBnB benefitted massively from the housing bubble & financial crisis (3 years after formation), which created a large class of people who were desperate for income and whose primary residence was their primary income-producing asset. Uber had to try the idea multiple times before cell phone batteries became good enough to run navigation continuously in the car (2 years after formation), and took off because of the publicity of getting sued by San Francisco. WhatsApp took off after the addition of push notifications to iOS (~18 months after formation) made it feasible to use as a messenger rather than just a status update.
All of these companies certainly did things to influence their success, in particular having a product on the market at the time the market changed to take advantage of the product. But for most of them the product was actually wrong in the sense that it was a complete failure in the market until that market changed. Brian Chesky's fond of calling AirBnB "the worst startup idea that actually worked".
It's like the formula for success = preparedness + luck. This cribsheet does a good job at preparedness, but you have to acknowledge the role of luck if you want to actually capitalize on that preparedness, and being afraid to work on the wrong ideas will often shut you out of ideas that require some luck to work.
I like the bottom-line perspective you provide at the end, of "success = preparedness + luck."
Preparedness is what we can train ourselves for, and preparedness also has the effect of making you more able to see and take advantage of opportunities that come your way. And to someone who doesn't know how much you've prepared, it appears that you're just luckier.
Preparedness is what we can train ourselves for, and preparedness also has the effect of making you more able to see and take advantage of opportunities that come your way. And to someone who doesn't know how much you've prepared, it appears that you're just luckier.
I used to work for a startup whose founder loved quoting Louis Pasteur: "Fortune favors the well-prepared mind." Then again, that dude was building a medical device based on his PhD research. Most Silicon Valley founders would scoff at that quote.
What was the outcome of that startup? Did the product make it to market?
I'm currently working on commercialising a pharmaceutical manufacturing monitoring device[1], based on the work from someone's PhD.
[1] https://www.phyllon.at
I'm currently working on commercialising a pharmaceutical manufacturing monitoring device[1], based on the work from someone's PhD.
[1] https://www.phyllon.at
But these examples are cherry picked. Was Google lucky? Oracle? Hotmail? Take away what luck might exist, and would they not still be billion dollar companies?
> But without the benefit of hindsight, how do you tell the difference?
See value missed by others.
Do you have sources for any of the success factors you described? My understanding was that WhatsApp's success was largely due to focusing on feature phones, increasing ubiquity.
Regardless, none of this changes the fact that OP is correct in saying that you shouldn't work on the wrong ideas, of course.
See value missed by others.
Do you have sources for any of the success factors you described? My understanding was that WhatsApp's success was largely due to focusing on feature phones, increasing ubiquity.
Regardless, none of this changes the fact that OP is correct in saying that you shouldn't work on the wrong ideas, of course.
WhatsApp's push notification story is in the Wikipedia page, though I think I'd read it in a news story profiling Jan Koum after the acquisition:
https://en.wikipedia.org/wiki/WhatsApp#History
I was wrong about timing though: it was only about 6 months after WhatsApp was incorporated (2 years after they left Yahoo though, so they might have been working on it beforehand).
https://en.wikipedia.org/wiki/WhatsApp#History
I was wrong about timing though: it was only about 6 months after WhatsApp was incorporated (2 years after they left Yahoo though, so they might have been working on it beforehand).
>> It's like the formula for success = preparedness + luck.
Would saying "success = preparedness * luck" be better?
Would saying "success = preparedness * luck" be better?
Like communism!
> is that the people who are best positioned to capitalize on an emerging technology wave are the ones who started working on it before anyone realized it was important, just because it was interesting to them
Its not just “interesting” there is also happenstance
There are going to be college kids working on “XEM Smart Contracts” for some ICO consultancy startup just because they had more java classes across semesters
And they will be heralded as pioneering geniuses just because some fortune 500 starts looking for the word smart contract on linkedin
Its not just “interesting” there is also happenstance
There are going to be college kids working on “XEM Smart Contracts” for some ICO consultancy startup just because they had more java classes across semesters
And they will be heralded as pioneering geniuses just because some fortune 500 starts looking for the word smart contract on linkedin
This is totally an incomplete thought, and I'm not trying to be down on this author in particular:
It's interesting to see a lot of management thoughts and colloquialisms slowly creep into the "other side" of software development (i.e. the actual developers) and become fairly well-tolerated.
We still make fun of phrases like "paradigm" or "synergy", but we're all mostly on-board with phrases like "own <x>" or "growth mindset". You can see the author using the word "leverage" here repeatedly in the same way that we often chide managers for using words like "synergy".
Interestingly the conversation around "effective engineers" has also shifted to really de-emphasize that technical ability - the best engineer is a good teammate, first and foremost (and I think a not-so-subtle implication also is that a good engineer is mostly extroverted as well). In the past decade or so, it seems like the "effective engineer" has become one who straddles that line between management and technical ability.
I don't really have an opinion on this yet (I think there's good and bad, as with most things), but it's just fascinating to watch.
It's interesting to see a lot of management thoughts and colloquialisms slowly creep into the "other side" of software development (i.e. the actual developers) and become fairly well-tolerated.
We still make fun of phrases like "paradigm" or "synergy", but we're all mostly on-board with phrases like "own <x>" or "growth mindset". You can see the author using the word "leverage" here repeatedly in the same way that we often chide managers for using words like "synergy".
Interestingly the conversation around "effective engineers" has also shifted to really de-emphasize that technical ability - the best engineer is a good teammate, first and foremost (and I think a not-so-subtle implication also is that a good engineer is mostly extroverted as well). In the past decade or so, it seems like the "effective engineer" has become one who straddles that line between management and technical ability.
I don't really have an opinion on this yet (I think there's good and bad, as with most things), but it's just fascinating to watch.
It's less about management and technical ability, and more about soft skills and hard skills.
A recent Washington Post article shared an analytical study from Google on what made engineers at the company successful:
"Project Oxygen shocked everyone by concluding that, among the eight most important qualities of Google’s top employees, STEM expertise comes in dead last. The seven top characteristics of success at Google are all soft skills: being a good coach; communicating and listening well; possessing insights into others (including others different values and points of view); having empathy toward and being supportive of one’s colleagues; being a good critical thinker and problem solver; and being able to make connections across complex ideas."
Unfortunately, almost all computer science education nowadays focuses on pure technical skills and hiring interviews at most tech companies also focus on the technical skills. The impact is that many engineers plateau in their careers because they've underinvested in (and oftentimes looked down upon) the "soft skills" that actually separate the top engineers from everyone else.
Here's the article: https://www.washingtonpost.com/news/answer-sheet/wp/2017/12/...
A recent Washington Post article shared an analytical study from Google on what made engineers at the company successful:
"Project Oxygen shocked everyone by concluding that, among the eight most important qualities of Google’s top employees, STEM expertise comes in dead last. The seven top characteristics of success at Google are all soft skills: being a good coach; communicating and listening well; possessing insights into others (including others different values and points of view); having empathy toward and being supportive of one’s colleagues; being a good critical thinker and problem solver; and being able to make connections across complex ideas."
Unfortunately, almost all computer science education nowadays focuses on pure technical skills and hiring interviews at most tech companies also focus on the technical skills. The impact is that many engineers plateau in their careers because they've underinvested in (and oftentimes looked down upon) the "soft skills" that actually separate the top engineers from everyone else.
Here's the article: https://www.washingtonpost.com/news/answer-sheet/wp/2017/12/...
among the eight most important qualities of Google’s top employees, STEM expertise comes in dead last.
I have a lot of those soft skills. But no one is going to hire me as an engineer because I don't have the coding skills.
It comes in dead last because you have to have high level coding skills to get your foot in the door. Everyone has that. Getting ahead in that crowd means having others assets on top of being a good coder.
It is a little like saying "Height doesn't matter for success as a basketball player. As long as you are at least 6'6", what matters are these other attributes." Yeah, sure, cool. It isn't a strong differentiator for the in crowd because you can't even join the crowd without it.
I have a lot of those soft skills. But no one is going to hire me as an engineer because I don't have the coding skills.
It comes in dead last because you have to have high level coding skills to get your foot in the door. Everyone has that. Getting ahead in that crowd means having others assets on top of being a good coder.
It is a little like saying "Height doesn't matter for success as a basketball player. As long as you are at least 6'6", what matters are these other attributes." Yeah, sure, cool. It isn't a strong differentiator for the in crowd because you can't even join the crowd without it.
I agree. If everyone at some company meets some bar for expertise, then differentiation among peers comes elsewhere.
>Project Oxygen shocked everyone by concluding that, among the eight most important qualities of Google’s top employees, STEM expertise comes in dead last.
This result seems a bit unsurprising. People who work at Google would already be in the top n-th percent in terms of STEM expertise. If everyone you hire is 'above average' then being a bit better than that has marginal gains and other factors would lead to your success. I'd be curious to see how this plays out at smaller firms where they cannot afford to hire the top-end STEM expertise.
This result seems a bit unsurprising. People who work at Google would already be in the top n-th percent in terms of STEM expertise. If everyone you hire is 'above average' then being a bit better than that has marginal gains and other factors would lead to your success. I'd be curious to see how this plays out at smaller firms where they cannot afford to hire the top-end STEM expertise.
Your observation is a great one, and I'd love to see more data on this as well.
A related point, though, also rings true. Soft skills like being a good coach and effective listening are so underinvested in, that even marginal improvements in those skills lead to huge differences in success.
I see this in engineering leadership workshops that I've run with Jean Hsu and Diana Berlin, where even teaching a handful of coaching and listening skills can have a transformative impact on participants.
If you're interested in future workshops, you can sign up to hear about them here: https://effectiveengineer.typeform.com/to/cDMeZu
A related point, though, also rings true. Soft skills like being a good coach and effective listening are so underinvested in, that even marginal improvements in those skills lead to huge differences in success.
I see this in engineering leadership workshops that I've run with Jean Hsu and Diana Berlin, where even teaching a handful of coaching and listening skills can have a transformative impact on participants.
If you're interested in future workshops, you can sign up to hear about them here: https://effectiveengineer.typeform.com/to/cDMeZu
Do you have any ideas on how companies can better assess soft skills during interviews?
At Quip, we run one coding interview that happens on a laptop, and where your conversation and discussions with the interviewer, including how you handle suggestions and feedback, matter a huge deal.
For experienced hires, we'll do deep dives on technical projects that they've worked on. Sometimes, I'll frame these as "Suppose I'm a new member joining that team. Bring me up to speed." These interviews focus on whether the candidate can clearly articulate concepts, explain the big-picture motivations, defend decisions they've made, understand complex technical problems, and stay humble and share lessons learned.
For manager interviews, we'll also do interviews that are one-on-ones with engineers on actual issues that they're facing.
For experienced hires, we'll do deep dives on technical projects that they've worked on. Sometimes, I'll frame these as "Suppose I'm a new member joining that team. Bring me up to speed." These interviews focus on whether the candidate can clearly articulate concepts, explain the big-picture motivations, defend decisions they've made, understand complex technical problems, and stay humble and share lessons learned.
For manager interviews, we'll also do interviews that are one-on-ones with engineers on actual issues that they're facing.
> we'll also do interviews that are one-on-ones with engineers on actual issues that they're facing.
Be careful with this approach. If you're not paying candidates for their interview time, you're not allowed to use their work. Big companies go to great lengths to demonstrate that the entire interview is for the purpose of a hiring decision and nothing more. This is to limit liability. Your approach is very dangerous for your company and if an unhired candidate's idea shows up in your product, even if you arrived at that result independent of the interview, the candidate has a strong case against you in a lawsuit.
If you're doing interviews like this, be sure you've discussed all the nuances with your company's lawyers.
Be careful with this approach. If you're not paying candidates for their interview time, you're not allowed to use their work. Big companies go to great lengths to demonstrate that the entire interview is for the purpose of a hiring decision and nothing more. This is to limit liability. Your approach is very dangerous for your company and if an unhired candidate's idea shows up in your product, even if you arrived at that result independent of the interview, the candidate has a strong case against you in a lawsuit.
If you're doing interviews like this, be sure you've discussed all the nuances with your company's lawyers.
Do you just want something that assesses soft skills?
Or do you also want something where all your interviewers will give the same candidate the same score, and that's robust against being gamed?
The former is easy: "Tell me about a time you helped a colleague improve their performance", "What do you think makes for a good coach?" etc etc.
The latter? I've never seen a convincing way of doing it.
Or do you also want something where all your interviewers will give the same candidate the same score, and that's robust against being gamed?
The former is easy: "Tell me about a time you helped a colleague improve their performance", "What do you think makes for a good coach?" etc etc.
The latter? I've never seen a convincing way of doing it.
I strongly agree with this analysis. It's already a population with strong STEM abilities, it should suffer from some sort of diminishing returns after an already high hiring standard on a company well-known for hiring only top students.
It's like conducting an analysis on skills of all F-1 drivers, and what differentiates champions from remaining pilots. I'd expect a lot of mindset-related and soft skills to appear as key indicators, and "driving abilities" to have a minimal gap between drivers.
It's like conducting an analysis on skills of all F-1 drivers, and what differentiates champions from remaining pilots. I'd expect a lot of mindset-related and soft skills to appear as key indicators, and "driving abilities" to have a minimal gap between drivers.
This would be like a study that found that height was completely uncorrelated with performance in the NBA. Doesn't mean that height is irrelevant in basketball, only that selection bias is in full effect and that we're not looking at a 'normal' population with respect to height. Same IMO with respect to google and engineering skill.
This makes so much sense and frequently overlooked. I find even in other areas (such as sports), what makes someone seem really impressive generally isn't what is actually important.
A dumb example is from cycling, people frequently over-practice the ability to sprint at the end of a race but what is really important is the ability to conserve energy throughout the race... Really dumb example, but I think it is somewhat similar.
A dumb example is from cycling, people frequently over-practice the ability to sprint at the end of a race but what is really important is the ability to conserve energy throughout the race... Really dumb example, but I think it is somewhat similar.
Another likely bias is that success is probably measured by peer review, and peers are more likely to overvalue soft skills.
Is there any evidence this is happening? I work at Google and as a lower level engineer more often than not wish some of the leads had better soft skills which makes me think they're not emphasized nearly enough in terms of promotion, which is at least one measure of success.
I believe promotion committees try to see measurable impact, which at least to me sounds like soft skills unfortunately don't help much..
I believe promotion committees try to see measurable impact, which at least to me sounds like soft skills unfortunately don't help much..
Hopefully this will not morph into another recruiting mantra like it went with bullshit interview questions.
I can’t speak to this particular study, but as a former Google employee, I would take any of the social “research” done at Google with a massive grain of salt. Very little is peer reviewed (or even externally available) and the stuff I looked at internally is not even remotely rigorous.
Additionally, the results that make it to the media get way exaggerated compared to the actual underlying study. This is compounded by the fact that Google picks and chooses what it publicizes, so what you’re seeing has a huge PR/political filter.
Additionally, the results that make it to the media get way exaggerated compared to the actual underlying study. This is compounded by the fact that Google picks and chooses what it publicizes, so what you’re seeing has a huge PR/political filter.
> Unfortunately, almost all computer science education nowadays focuses on pure technical skills
Assuming by computer science education you mean the actual classes within that major, I don't see this as a problem. I didn't take CS classes to learn interpersonal relationship skills. Other college classes and the college experience in general does help with that though.
If talking about tech programs, I also think that isn't necessarily something they can or should focus too much on, as that's not their focus. The assumption is you have that part already figured out. If not, go through a course that focuses on that in addition, I'm sure you'll get a better education in that topic that way. It probably is appropriate for them to stress it's important though, even if they don't offer much in the way of rectifying it.
Or, spend a lot of time on self-directed self improvement in one or both those areas. The resources and programs exist for that as well.
> and hiring interviews at most tech companies also focus on the technical skills.
I agree on this. Companies should hire people that will function within their system. Hiring the smartest guy from MIT's class of 2017 sounds all well and good, but if they can't function well with your existing 100 employees and they leave after a year or two (or worse, they cause a few other people at your company to leave every year causing high turnover), the chances of them somehow making up for that are probably extremely low.
Assuming by computer science education you mean the actual classes within that major, I don't see this as a problem. I didn't take CS classes to learn interpersonal relationship skills. Other college classes and the college experience in general does help with that though.
If talking about tech programs, I also think that isn't necessarily something they can or should focus too much on, as that's not their focus. The assumption is you have that part already figured out. If not, go through a course that focuses on that in addition, I'm sure you'll get a better education in that topic that way. It probably is appropriate for them to stress it's important though, even if they don't offer much in the way of rectifying it.
Or, spend a lot of time on self-directed self improvement in one or both those areas. The resources and programs exist for that as well.
> and hiring interviews at most tech companies also focus on the technical skills.
I agree on this. Companies should hire people that will function within their system. Hiring the smartest guy from MIT's class of 2017 sounds all well and good, but if they can't function well with your existing 100 employees and they leave after a year or two (or worse, they cause a few other people at your company to leave every year causing high turnover), the chances of them somehow making up for that are probably extremely low.
Our CS program had a "basic communication" class, where you learned to write basic reports, memos, emails, your resume, etc. The final project was investigating some piece of tech, writing a 30 page paper on it, and presenting your findings to the class. Other CS teachers were invited to drop in during the presentations too.
Supposedly they added this after receiving feedback from industry that the biggest problem was that their graduating students couldn't properly communicate.
Altogether it felt pretty appropriate, since it was still focused on CS related concepts.
Supposedly they added this after receiving feedback from industry that the biggest problem was that their graduating students couldn't properly communicate.
Altogether it felt pretty appropriate, since it was still focused on CS related concepts.
> Unfortunately, almost all computer science education nowadays focuses on pure technical skills
I'm not sure I'd really call that unfortunate. CS education isn't about making you a more well-rounded person: It's about giving you a basic education in Computer Science.
Similarly I don't really lament that CS programs don't have a course in basic financial literacy, even though it would be incredibly useful.
These are really topics that should be addressed much, much earlier (empathy in particular is something we should start teaching children as young as possible) and should be mature ideas by the time people reach college-age.
> The impact is that many engineers plateau in their careers because they've underinvested in (and oftentimes looked down upon) the "soft skills" that actually separate the top engineers from everyone else.
To mirror the other comment, I hate to say it but if you're a software engineer at Google you're likely already a "top" engineer.
You're trying to explain what differentiates the top 0.1% from the top 1%, but I'm not sure it's a super useful distinction for the other 99%. For them, investment in hard skills might actually be considerably more fruitful (and land them that Google job in the first place).
Maybe not, I'll admit I could easily be wrong on that.
I'm not sure I'd really call that unfortunate. CS education isn't about making you a more well-rounded person: It's about giving you a basic education in Computer Science.
Similarly I don't really lament that CS programs don't have a course in basic financial literacy, even though it would be incredibly useful.
These are really topics that should be addressed much, much earlier (empathy in particular is something we should start teaching children as young as possible) and should be mature ideas by the time people reach college-age.
> The impact is that many engineers plateau in their careers because they've underinvested in (and oftentimes looked down upon) the "soft skills" that actually separate the top engineers from everyone else.
To mirror the other comment, I hate to say it but if you're a software engineer at Google you're likely already a "top" engineer.
You're trying to explain what differentiates the top 0.1% from the top 1%, but I'm not sure it's a super useful distinction for the other 99%. For them, investment in hard skills might actually be considerably more fruitful (and land them that Google job in the first place).
Maybe not, I'll admit I could easily be wrong on that.
There's for sure a tricky balance on what fits into a CS education.
I remember when I was at MIT (oof, over a decade ago), many project-based CS courses where students were just put into teams and expected teamwork to just happen. Sometimes people got along, and the project would go fine. Other times, not so much.
I know I certainly wasn't very well-equipped to handle tension or to have hard conversations about fair distribution of work. And back them, I ended up just avoiding them. Knowing what I know now, even a single lecture on tools for more effective teams or for having hard conversations or giving feedback would have made those projects SO much more valuable in terms of being learning experiences.
Given that effectively using your CS education will involve collaborating with other people to some degree, I do believe that giving more emphasis to the non-technical skills that play a big role in your career would have a hugely positive impact.
I remember when I was at MIT (oof, over a decade ago), many project-based CS courses where students were just put into teams and expected teamwork to just happen. Sometimes people got along, and the project would go fine. Other times, not so much.
I know I certainly wasn't very well-equipped to handle tension or to have hard conversations about fair distribution of work. And back them, I ended up just avoiding them. Knowing what I know now, even a single lecture on tools for more effective teams or for having hard conversations or giving feedback would have made those projects SO much more valuable in terms of being learning experiences.
Given that effectively using your CS education will involve collaborating with other people to some degree, I do believe that giving more emphasis to the non-technical skills that play a big role in your career would have a hugely positive impact.
> I know I certainly wasn't very well-equipped to handle tension or to have hard conversations about fair distribution of work.
I guess my point is more that primary school really should've prepared you for this: Group dynamics and how to handle these "group tensions" is more of a basic learning skill that we should be developing very early on.
I'm not arguing that this is a useless skill to teach, more that it's far more expensive and much less effective for MIT to be teaching you these skills and not MyTown elementary/middle/high school.
I guess my point is more that primary school really should've prepared you for this: Group dynamics and how to handle these "group tensions" is more of a basic learning skill that we should be developing very early on.
I'm not arguing that this is a useless skill to teach, more that it's far more expensive and much less effective for MIT to be teaching you these skills and not MyTown elementary/middle/high school.
Why can't the managers with business backgrounds be the social engineers expertly manipulating the asocial software engineers? I thought that's what they were for. Distribution of labor!
I think for me it's more like:
One of the fundamental duties of a middle manager is to worry about group dynamics, team effectiveness, group communication, etc.
If the engineers are now doing all of that as well, what's middle management doing?
("Nothing, same as always" is of course the snarky answer)
One of the fundamental duties of a middle manager is to worry about group dynamics, team effectiveness, group communication, etc.
If the engineers are now doing all of that as well, what's middle management doing?
("Nothing, same as always" is of course the snarky answer)
There are quite a few implicit assumptions here that make it a dubious example, though.
For example, there's an assumption that what works well at Google would work well for other tech firms. And yet Google is in the rare position of having gained so much from its early golden goose that success in terms of producing viable, valuable products and services has been almost irrelevant among most of its workforce for most of its existence.
There's also an assumption that the staff at a big, famous organisation like Google are generally better than those elsewhere, and therefore that being successful in such an organisation is something to be emulated. Working at one of the Big Five seems like a default aspiration for some parts of the tech world, and there's definitely an element of hero worship for those who have made it. I can't help wondering whether that is simply because of the amount of money they can throw at new starters in the hope that they attract some of the best people among the catch.
What I see here is that if you're in an environment where being good at walking the walk isn't always necessary, talking a good talk becomes the path to recognition and success. While this is almost certainly true, anyone who's ever observed the phenomenon of middle management could have told you that, without reference to any specific industry. What it doesn't tell us is how much being able to walk the walk matters in most other environments where it is necessary for success.
For example, there's an assumption that what works well at Google would work well for other tech firms. And yet Google is in the rare position of having gained so much from its early golden goose that success in terms of producing viable, valuable products and services has been almost irrelevant among most of its workforce for most of its existence.
There's also an assumption that the staff at a big, famous organisation like Google are generally better than those elsewhere, and therefore that being successful in such an organisation is something to be emulated. Working at one of the Big Five seems like a default aspiration for some parts of the tech world, and there's definitely an element of hero worship for those who have made it. I can't help wondering whether that is simply because of the amount of money they can throw at new starters in the hope that they attract some of the best people among the catch.
What I see here is that if you're in an environment where being good at walking the walk isn't always necessary, talking a good talk becomes the path to recognition and success. While this is almost certainly true, anyone who's ever observed the phenomenon of middle management could have told you that, without reference to any specific industry. What it doesn't tell us is how much being able to walk the walk matters in most other environments where it is necessary for success.
The prase "success of people working at X is correlated with Y" has about the same meaning of "X recruitment process is weakest on select Y".
The seven top characteristics of success at Google are all soft skills: being a good coach; communicating and listening well; possessing insights into others (including others different values and points of view); having empathy toward and being supportive of one’s colleagues; being a good critical thinker and problem solver; and being able to make connections across complex ideas."
That is describing what it takes for an individual to be successful in a group of men. I think Im safe in saying this is like that since the dawn of men. Specifically here, it happens in organisations big enough so that people's actual productivity is unknown.
Innovation though generally doesn't happen in such environment.
That is describing what it takes for an individual to be successful in a group of men. I think Im safe in saying this is like that since the dawn of men. Specifically here, it happens in organisations big enough so that people's actual productivity is unknown.
Innovation though generally doesn't happen in such environment.
[deleted]
> Project Oxygen shocked everyone by concluding that, among the eight most important qualities of Google’s top employees, STEM expertise comes in dead last.
And yet it seems to me that the typical software/technical interview process emphasizes #8 more than the other seven. Maybe like the drunkard searching for lost keys under the lamp post. Quite sobering.
And yet it seems to me that the typical software/technical interview process emphasizes #8 more than the other seven. Maybe like the drunkard searching for lost keys under the lamp post. Quite sobering.
"Project Oxygen shocked everyone by concluding that, among the eight most important qualities of Google’s top employees, STEM expertise comes in dead last. The seven top characteristics of success at Google are all soft skills"
Worth keeping in mind that this is true for the culture/environment within Google, not universally. Different companies have different cultures, and the above actually makes me more cynical about the culture within Google. If two people have competing ideas for a engineering solution/implementation, is the winner going to be the one with the best technical merits, or the one best at office politics? Judging from the above study, it seems like Google's culture is less meritocracy-driven and more politics-driven than people think.
Worth keeping in mind that this is true for the culture/environment within Google, not universally. Different companies have different cultures, and the above actually makes me more cynical about the culture within Google. If two people have competing ideas for a engineering solution/implementation, is the winner going to be the one with the best technical merits, or the one best at office politics? Judging from the above study, it seems like Google's culture is less meritocracy-driven and more politics-driven than people think.
This is the article that argues that for people in the top 1% of STEM expertise, STEM expertise isn't the distinguishing factor.
Frankly, it would be surprising if it was. If you've topped out that tech tree, most of your performance variance will come from other areas where there's more, uh, variance.
Frankly, it would be surprising if it was. If you've topped out that tech tree, most of your performance variance will come from other areas where there's more, uh, variance.
I did some reading into project Oxygen. From what I could tell it set out to find the most important qualities for managers at google, which made the results much less surprising. I would love to find more info on this either way.
This is a mindset that I encountered a lot from managers and VPs at Google. The premise is that the best way to improve one's incremental technical contribution is to improve an entire team.
If you bust your ass for a year and improve your own technical chops, you might be able to implement stuff 10% faster. Instead, you could help a team of 30 people to produce 10% more work. This is achievable from my anecdotal experience, but citation needed. At this point, you can throw your 10% incremental improvement out the window because now your incremental engineering improvement is 10% of a 30 person team, or 3 engineers. Now imagine you organized a department of 300 engineers to develop the right mix of infrastructure, forward-looking projects, and core projects such that the organization runs and grows efficiently. Now your incremental technical contribution is so much larger than the initial 10% that it's laughable.
This doesn't have to be limited to management, which is where I think the Google VP perspective falls a little flat. You can do this kind of work through pure technical contributions. I think managers write about this kind of leverage more often, but it can come from any kind of organization. A core library or tool has a massive impact, because it's reusable past the bounds of your team. Maybe you're change isn't 10% distributed across 30 people, but you could improve 3000 people by 1%.
If you bust your ass for a year and improve your own technical chops, you might be able to implement stuff 10% faster. Instead, you could help a team of 30 people to produce 10% more work. This is achievable from my anecdotal experience, but citation needed. At this point, you can throw your 10% incremental improvement out the window because now your incremental engineering improvement is 10% of a 30 person team, or 3 engineers. Now imagine you organized a department of 300 engineers to develop the right mix of infrastructure, forward-looking projects, and core projects such that the organization runs and grows efficiently. Now your incremental technical contribution is so much larger than the initial 10% that it's laughable.
This doesn't have to be limited to management, which is where I think the Google VP perspective falls a little flat. You can do this kind of work through pure technical contributions. I think managers write about this kind of leverage more often, but it can come from any kind of organization. A core library or tool has a massive impact, because it's reusable past the bounds of your team. Maybe you're change isn't 10% distributed across 30 people, but you could improve 3000 people by 1%.
Yeah, and I think this is where it's fair for the author to use terms like "leverage", since you're effectively multiplying force.
To be fair, though, I don't think having that team-first mentality (where you're focused on improving the team's productivity as opposed to your own) necessarily implies pervasive "management thinking" (for lack of a better phrase) or even soft skills. I imagine we can all think of teams where that isn't the case.
To be fair, though, I don't think having that team-first mentality (where you're focused on improving the team's productivity as opposed to your own) necessarily implies pervasive "management thinking" (for lack of a better phrase) or even soft skills. I imagine we can all think of teams where that isn't the case.
This Leverage concept can be applied to a family .
Instead of YOU, as head of household putting more hours to solve Home chores/issues, if you teach other 3 members of your family how to solve issues/do chores , you get 3X return .
An example is online shopping for Home: Instead of you spending time for all the research each time, teaching family members, you can achieve leverage .
> If you bust your ass for a year and improve your own technical chops, you might be able to implement stuff 10% faster. Instead, you could help a team of 30 people to produce 10% more work. This is achievable from my anecdotal experience, but citation needed.
> At this point, you can throw your 10% incremental improvement out the window because now your incremental engineering improvement is 10% of a 30 person team, or 3 engineers
Instead of YOU, as head of household putting more hours to solve Home chores/issues, if you teach other 3 members of your family how to solve issues/do chores , you get 3X return .
An example is online shopping for Home: Instead of you spending time for all the research each time, teaching family members, you can achieve leverage .
> If you bust your ass for a year and improve your own technical chops, you might be able to implement stuff 10% faster. Instead, you could help a team of 30 people to produce 10% more work. This is achievable from my anecdotal experience, but citation needed.
> At this point, you can throw your 10% incremental improvement out the window because now your incremental engineering improvement is 10% of a 30 person team, or 3 engineers
I think you're being a little too pessimistic, although I do see where you're coming from. Technical jargon and vocabulary aren't created out of thin air: they are meant to efficiently and effectively convey certain facts and behaviors. Sometimes (perhaps many times?) there are co-opted and misused by certain people (many times managers, since they're further away from actual coding).
The thing about engineer being a good teammate: I don't think it is about extroversion as much as realizing that modern software systems are very non-monolithic and thus require cooperation among many different services to work effectively. This means that the days when a person could write the entire thing by himself/herself is over, and a lot more co-operation is required among engineers to design and build effective systems. That cooperation requires a certain amount of communication skills (apart from stellar technical skills), but it doesn't mean that you have to be an extrovert.
The thing about engineer being a good teammate: I don't think it is about extroversion as much as realizing that modern software systems are very non-monolithic and thus require cooperation among many different services to work effectively. This means that the days when a person could write the entire thing by himself/herself is over, and a lot more co-operation is required among engineers to design and build effective systems. That cooperation requires a certain amount of communication skills (apart from stellar technical skills), but it doesn't mean that you have to be an extrovert.
I think often lost from the whole introversion vs extroversion debate is that:
1. It's not a binary. It's a bell curve where many people fit near the middle and some are extreme outliers in either direction.
I know personally that I am an introvert, but I confuse a lot of proclaimed extroverts who mistake me for being extroverted because I have a fairly gregarious and willing to try anything once personality.
2. Introvert / extrovert really has nothing to do with communication skills except that introverts appear to be bad at verbal communication usually because that skill isn't as practiced as extroverts. But good verbal communication is totally a developable skill rather than something innate to a person.
1. It's not a binary. It's a bell curve where many people fit near the middle and some are extreme outliers in either direction.
I know personally that I am an introvert, but I confuse a lot of proclaimed extroverts who mistake me for being extroverted because I have a fairly gregarious and willing to try anything once personality.
2. Introvert / extrovert really has nothing to do with communication skills except that introverts appear to be bad at verbal communication usually because that skill isn't as practiced as extroverts. But good verbal communication is totally a developable skill rather than something innate to a person.
This means that the days when a person could write the entire thing by himself/herself is over, and a lot more co-operation is required among engineers to design and build effective systems.
At that point, you're not really talking about being an effective engineer, though. You're only talking about being an effective engineer in a large organisation working on a large project.
I know plenty of people in the freelancing and startup world who can build and maintain very significant systems single-handedly. Take someone with the skill and experience to do that, give them a free hand in choosing whatever tools and processes work for them to get a good job done, and remove the overheads of micromanaging this and co-ordinating that. It's not unusual for that person to outperform an entire team working for a competitor under more traditional constraints, or for a small number of such people who can keep the overheads down to outperform a more traditionally organised but mediocre team an order of magnitude larger. Of course these people also need good soft skills, but those are not why they are so productive.
At that point, you're not really talking about being an effective engineer, though. You're only talking about being an effective engineer in a large organisation working on a large project.
I know plenty of people in the freelancing and startup world who can build and maintain very significant systems single-handedly. Take someone with the skill and experience to do that, give them a free hand in choosing whatever tools and processes work for them to get a good job done, and remove the overheads of micromanaging this and co-ordinating that. It's not unusual for that person to outperform an entire team working for a competitor under more traditional constraints, or for a small number of such people who can keep the overheads down to outperform a more traditionally organised but mediocre team an order of magnitude larger. Of course these people also need good soft skills, but those are not why they are so productive.
> That cooperation requires a certain amount of communication skills (apart from stellar technical skills), but it doesn't mean that you have to be an extrovert.
There are many people (including myself) who can operate quite successfully in the text-based world (Slack, email) and collaborate that way.
I think Slack (and other tools like it) helps the introvert be a more active participant or even a leader in certain technical discussions. Most especially, the ones where the servers are melting down.
There are many people (including myself) who can operate quite successfully in the text-based world (Slack, email) and collaborate that way.
I think Slack (and other tools like it) helps the introvert be a more active participant or even a leader in certain technical discussions. Most especially, the ones where the servers are melting down.
That's very true! I wasn't really thinking about Slack/etc. when I made that statement. Excellent point.
> That cooperation requires a certain amount of communication skills (apart from stellar technical skills), but it doesn't mean that you have to be an extrovert.
Yeah, and I realize it's a spectrum and not a binary thing. My point was more:
If we use the simplistic, trendy definition of introversion/extroversion as "do you gain energy having conversations or does it require energy?" and then say that regular conversations are an extremely important part of doing modern development work, I think it's fair to say that you're implicitly selecting for extroverts.
And again, I don't really put a judgement on that. I think it's fair to say "regular conversations are required to be successful as a software developer." I'm just noting the shift (as you've also done!).
Yeah, and I realize it's a spectrum and not a binary thing. My point was more:
If we use the simplistic, trendy definition of introversion/extroversion as "do you gain energy having conversations or does it require energy?" and then say that regular conversations are an extremely important part of doing modern development work, I think it's fair to say that you're implicitly selecting for extroverts.
And again, I don't really put a judgement on that. I think it's fair to say "regular conversations are required to be successful as a software developer." I'm just noting the shift (as you've also done!).
"Leverage" has real meaning. Another word for it that you might be more familiar with from software is "reuse".
Reuse is leverage. If a piece of software (function, class, module, service, tool, whatever) is used for 1 task, it's not leveraged. If it's used for 10 tasks, that means the creation of the reused thing had 10x leverage: working on that reused thing created 10 times more value than working on something that's only used once.
It's not quite that straightforward as everyone knows, there are costs to reuse (abstractions (both lowest common denominator and leakage), more dependencies, higher maintenance costs owing to risk of breakage of multiple clients, etc.). But the leverage is very often real.
Reuse is leverage. If a piece of software (function, class, module, service, tool, whatever) is used for 1 task, it's not leveraged. If it's used for 10 tasks, that means the creation of the reused thing had 10x leverage: working on that reused thing created 10 times more value than working on something that's only used once.
It's not quite that straightforward as everyone knows, there are costs to reuse (abstractions (both lowest common denominator and leakage), more dependencies, higher maintenance costs owing to risk of breakage of multiple clients, etc.). But the leverage is very often real.
What's your point? Synergy has real meaning as well. The problem is when concepts like leverage or synergy become goals in and of themselves. That might be something you'd expect from someone who's read a lot of management books, but you'd expect engineers to see these as means to an end.
While I don’t advocate the use of these terms in every situation, it’s hard to have all ends in mind and to carefully choose which tool should be applied to each end. That may be why these properties are used as goals. Easier to spot, easier to reason about. Basically, they are heuristics.
> You can see the author using the word "leverage" here repeatedly
Or maybe devs/engineers are just growing more eloquent than used to be? "Leverage" is truly the most intrinsic essence of everything engineering/developing. Reducing man-days, eliminating manual efforts, extracting infinitely reusable abstractions, code that emits+evals code .. I could go on and on and on --- hard to find a more sufficiently terse umbrella moniker that captures the mindset behind it all than "leverage"!
Or maybe devs/engineers are just growing more eloquent than used to be? "Leverage" is truly the most intrinsic essence of everything engineering/developing. Reducing man-days, eliminating manual efforts, extracting infinitely reusable abstractions, code that emits+evals code .. I could go on and on and on --- hard to find a more sufficiently terse umbrella moniker that captures the mindset behind it all than "leverage"!
I've heard multiple similar arguments in favor of the word "synergy" or "paradigm".
Let me turn the tables: Why is "leverage" acceptable to use but "synergy" engenders scoffing?
Let me turn the tables: Why is "leverage" acceptable to use but "synergy" engenders scoffing?
The terms themselves don't induce scoffing, it is the specific usage patterns over time, which then becomes associated with the term, devaluing it as a meaningful way to communicate.
Synergy was frequently used in a mindless, vague way by individuals who wished to appear in-the-know. Thus, it was devalued, as people actually in the know did not want to be mistaken for those those who didn't know how to use the term.
This dynamic usually happens with high-level abstractions that have much complexity and nuance, as it is difficult to assess if the term is being used in a meaningful way. "Paradigm" and "synergy" are good examples of such powerful yet tricky concepts prone to misuse and buzzification.
Some philosophers say that the meaning of a word is determined purely by its usage. In this view, a word like synergy loses much of its meaning, as it is commonly used in such a jumbled and unclear manner.
Synergy was frequently used in a mindless, vague way by individuals who wished to appear in-the-know. Thus, it was devalued, as people actually in the know did not want to be mistaken for those those who didn't know how to use the term.
This dynamic usually happens with high-level abstractions that have much complexity and nuance, as it is difficult to assess if the term is being used in a meaningful way. "Paradigm" and "synergy" are good examples of such powerful yet tricky concepts prone to misuse and buzzification.
Some philosophers say that the meaning of a word is determined purely by its usage. In this view, a word like synergy loses much of its meaning, as it is commonly used in such a jumbled and unclear manner.
> Synergy was frequently used in a mindless, vague way
Again, I'm really not trying to put the author down here - but "leverage" is a term that can very easily and often is used in a mindless and vague way. Not always, of course, in the same way that "synergy" can absolutely be used properly.
Still, it would be extremely easy for me to mindlessly posit whatever I want as "high impact", or at the very least "minimal time investment". "Minimal" and "high impact" are inherently subjective phrases (minimal compared to what? high compared to what?) and without a baseline are effectively useless.
So, I guess I still don't see a huge difference between "synergy" and "leverage" in terms of vagueness. And if vagueness exists, mindless usage is pretty soon to follow.
Again, I'm really not trying to put the author down here - but "leverage" is a term that can very easily and often is used in a mindless and vague way. Not always, of course, in the same way that "synergy" can absolutely be used properly.
Still, it would be extremely easy for me to mindlessly posit whatever I want as "high impact", or at the very least "minimal time investment". "Minimal" and "high impact" are inherently subjective phrases (minimal compared to what? high compared to what?) and without a baseline are effectively useless.
So, I guess I still don't see a huge difference between "synergy" and "leverage" in terms of vagueness. And if vagueness exists, mindless usage is pretty soon to follow.
I agree "leverage" is further down the spectrum of being prone to meaningless usage (than most words), but I don't think it is as far as "synergy".
It's a more precise concept: put x in, get more than x out. The more you get out for each input of x, the greater the leverage.
Synergy is the idea of "greater than the sum of the parts", which is a useful concept but much more nebulous, in my view.
Not that this is a particularly important debate :)
It's a more precise concept: put x in, get more than x out. The more you get out for each input of x, the greater the leverage.
Synergy is the idea of "greater than the sum of the parts", which is a useful concept but much more nebulous, in my view.
Not that this is a particularly important debate :)
I'll take that table-turn! Well my intuition here goes like so: think back to the first moment in life you heard about a "lever" --- then "synergy". Chances are, the former was an illuminating childhood moment when simple levering was first powerfully demonstrated to you by a peer or parent, and tickled your inner engineer/fixer-upper/tinkerer. Chances are, no comparable "engineerish" moment occurred when you first encountered the latter.
Probably the wrong person to ask :). The first time I heard the word "synergy" was downloading https://symless.com/synergy , which was an incredibly useful piece of software and absolutely did tickle my inner engineer (trying to figure out how it worked).
Fashion
As far as I'm aware, 'growth mindset' comes from education/psychology with Carol Dweck, not from management - did I miss something?
Not the first or the last time management has co-opted terms from academic fields :). Social psychology is especially ripe for this.
See also: "Paradigm shift" was coined by a physicist to talk about scientific revolutions, IIRC.
See also: "Paradigm shift" was coined by a physicist to talk about scientific revolutions, IIRC.
This frustrates me greatly. Many "engineering management" professors will show Dilbert strips and Office Space memes, then immediately fall into using the same kind of vocabulary that these works mocked.
(Recall that Initech in Office Space had "Hawaiian Shirt Fridays" - one of the core features of this manager-speak is to try to appear human and relevant as much as possible.)
(Recall that Initech in Office Space had "Hawaiian Shirt Fridays" - one of the core features of this manager-speak is to try to appear human and relevant as much as possible.)
I'm first in line to make fun of the title "scrum master" and other nonsense. But the things that have crept in seem to have because they work.
I'm results driven. I don't care who comes up with what or what it's named. If it works, I'm on board. If it doesn't, I'll lambast it.
I'm results driven. I don't care who comes up with what or what it's named. If it works, I'm on board. If it doesn't, I'll lambast it.
>But the things that have crept in seem to have because they work.
Keep in mind that things like Agile and Scrum might have had buy-in from team members because a team member adopting it wasn't as high of a cost as the same team member leaving the job. You might be able to object, but you'll probably be overridden.
There's some amount of reprogramming that happens there to keep the team cohesive, so people might begrudgingly adopt new habits. So in those cases, "it works" is barely sneaking in because everyone was forced to make it work.
It's not as easy to prove/disprove as more objective things like program performance, size, or correctness. There's a whole lot of flavors of "it works" out there.
Keep in mind that things like Agile and Scrum might have had buy-in from team members because a team member adopting it wasn't as high of a cost as the same team member leaving the job. You might be able to object, but you'll probably be overridden.
There's some amount of reprogramming that happens there to keep the team cohesive, so people might begrudgingly adopt new habits. So in those cases, "it works" is barely sneaking in because everyone was forced to make it work.
It's not as easy to prove/disprove as more objective things like program performance, size, or correctness. There's a whole lot of flavors of "it works" out there.
Many adults have an aversion to new words. Foods too! Over time, they grow accustomed.
I don't think so. Leverage has a precise concrete meaning in this article. We shouldn't avoid a descriptive accurate term just because it's for an abstract higher-order concept.
> Leverage has a precise concrete meaning in this article.
Er, not really. From the article:
> Leverage = Impact Produced / Time Invested
"Impact Produced" has a precise, concrete meaning?
Er, not really. From the article:
> Leverage = Impact Produced / Time Invested
"Impact Produced" has a precise, concrete meaning?
Sure. For software, it might be reuse of a component. Reuse leverages existing code. This is precise, unambiguous, and frankly uncontroversial.
> it might be
> This is... unambiguous,
:)
> This is... unambiguous,
:)
How about revenue or moving the needle on a key business metric like churn or order flow conversion rate.
"Synergy" is a precise term as well.
I do have an opinion on the phenomenon. There are more and more mediocre engineers who need this sort of thing in order to justify their existence.
Once the majority is mediocre, it becomes accepted practice.
Once the majority is mediocre, it becomes accepted practice.
Really great book! The things that stood out for me:
- Optimize for learning
- Invest in time-saving tools
- Shorten the debugging loop
- Don’t sprint in the middle of a marathon
- Recovery over prevention
- Automate mechanics, not decision making
- Make batch processes idempotent
We read it in the book club at work a year ago, and I wrote a longer review of it here: https://henrikwarne.com/2017/01/15/book-review-the-effective...
- Optimize for learning
- Invest in time-saving tools
- Shorten the debugging loop
- Don’t sprint in the middle of a marathon
- Recovery over prevention
- Automate mechanics, not decision making
- Make batch processes idempotent
We read it in the book club at work a year ago, and I wrote a longer review of it here: https://henrikwarne.com/2017/01/15/book-review-the-effective...
Awesome! Thanks for adding your notes to the discussion.
Hi! I'm Edmond, the author of the book. Happy to answer any questions about my two-year journey in self-publishing the book.
I saw your google tech talk a while ago, and I really like the concept of leverage even though I usually dislike this genre
https://www.youtube.com/watch?v=BnIz7H5ruy0 I think people get too religious about effectiveness.
I was wondering what you do when you don't want to follow a list of good things to do? I assume self-publishing was discouraging at times, wasn't it?
I was wondering what you do when you don't want to follow a list of good things to do? I assume self-publishing was discouraging at times, wasn't it?
Two things I've learned since writing the book:
1) It's also important to align your energy levels and what you want to do with your list of high-leverage tasks. When you're really excited about doing something, even if isn't strictly the highest-leverage thing you could do, you can actually end up creating more impact because you do a much better job of it.
2) Sometimes what's needed is just a change in perspective about things you need to do. I play with this a lot in the leadership coaching that I do. For example, I hate responding to emails because processing them all feels like a chore. But if I reframe responding to emails in my mind to be hunting for gems that might lead to new opportunities, I'm much more likely to go through them (at least the ones that are gems).
And oh yes, there were definitely discouraging points. The story about early, negative feedback from my wife (that I posted in another comment) was one.
Another is that ten months into book writing, around the start of 2014, I started feeling a sense of intense FOMO from reading Hacker News. Stripe had raised a valuation round of over $1B, and WhatsApp had been acquired for $16B. That led to moments where I would wonder "What in the world was I doing writing a book?" and "When will I ever finish?". I had just finished a first draft, I wasn't sure how rewarding financially the book would be, and I was feeling like I had removed myself from the startup game.
That led me to start looking for jobs, which quite fortunately, also led me to my current role at Quip. So everything worked out in the end.
1) It's also important to align your energy levels and what you want to do with your list of high-leverage tasks. When you're really excited about doing something, even if isn't strictly the highest-leverage thing you could do, you can actually end up creating more impact because you do a much better job of it.
2) Sometimes what's needed is just a change in perspective about things you need to do. I play with this a lot in the leadership coaching that I do. For example, I hate responding to emails because processing them all feels like a chore. But if I reframe responding to emails in my mind to be hunting for gems that might lead to new opportunities, I'm much more likely to go through them (at least the ones that are gems).
And oh yes, there were definitely discouraging points. The story about early, negative feedback from my wife (that I posted in another comment) was one.
Another is that ten months into book writing, around the start of 2014, I started feeling a sense of intense FOMO from reading Hacker News. Stripe had raised a valuation round of over $1B, and WhatsApp had been acquired for $16B. That led to moments where I would wonder "What in the world was I doing writing a book?" and "When will I ever finish?". I had just finished a first draft, I wasn't sure how rewarding financially the book would be, and I was feeling like I had removed myself from the startup game.
That led me to start looking for jobs, which quite fortunately, also led me to my current role at Quip. So everything worked out in the end.
Hi Edmond, is “high leverage” a phrase you use in the book? From the notes, “leverage” is defined as “impact / time invested.” Why did you choose “leverage” to describe this concept? “Leverage” suggests to me that it is grown with the idea of using it to climb a career ladder, but I’d like to hear your thoughts on this, as I have read just these notes and not the book yet.
Yes, "high-leverage" is a phrase I use in the book. I learned about leverage when I read Andy Grove's High Output Management.
Why the word leverage?
Time is our most limited resource. And so the way to really increase our impact (say by 10x) is not to increase the number of hours you work, but to increase your rate of impact, which is how I define leverage in the book.
Another way to think about leverage is in terms of a lever, which lets you apply a little bit of force, have it amplified, and then move large boulders. Many of the stories and strategies from the book talk about these leverage points in engineering, e.g. investing in iterating speed or validating your ideas early and often, where small bits of effort end up having a disproportionate impact.
Why the word leverage?
Time is our most limited resource. And so the way to really increase our impact (say by 10x) is not to increase the number of hours you work, but to increase your rate of impact, which is how I define leverage in the book.
Another way to think about leverage is in terms of a lever, which lets you apply a little bit of force, have it amplified, and then move large boulders. Many of the stories and strategies from the book talk about these leverage points in engineering, e.g. investing in iterating speed or validating your ideas early and often, where small bits of effort end up having a disproportionate impact.
What’s the right level of completion for validation? A few weeks for a prototype seems reasonable, but even that can result in feedback that isn’t or isn’t considered fast enough.
It depends. Easily communicated product ideas can be validated on day 0 by talking to users.
Less easily communicated ideas often need at least a demo. Dropbox is one example.
Less easily communicated ideas often need at least a demo. Dropbox is one example.
Thanks for your response, I understand it better now. Sorry for what must have seemed like a stupid question.
Leverage directly implies multiplication. Leverage, the physical concept, multiplies force or torque (rotational force). The analogy applies finance: multiplying your profitable strategy with borrowings to multiply the gains. The analogy also applies in software: multiply the uses of your code to increase the value it creates.
It seems to be the same as Return on investment. Could that be used interchangeably?
Hi Edmond, your book was great and I enjoyed reading it!
I do have a question on your topic on high leverage work; as a startup how would you know what is high leverage work? You have talked about various tooling projects at Quora which turned out to be duds, but how would you know that beforehand without trying? I guess the same applies to your book...
I do have a question on your topic on high leverage work; as a startup how would you know what is high leverage work? You have talked about various tooling projects at Quora which turned out to be duds, but how would you know that beforehand without trying? I guess the same applies to your book...
Awesome, I'm happy you enjoyed it!
In some sense, it might actually be easier to tell at a startup because what matters at a startup is growth. That can be growth of revenue (if you already have a product to sell) or growth of users (if you need traffic first to sell, e.g. Quora).
The highest-leverage work would then be the things that most directly lead to that growth. Sometimes, this will require talking with product managers or salespeople or users to understand what the biggest accelerators or roadblocks would be. So, for example, at Quip, I looked at data on how the product spread within teams and organizations, developed engagement metrics around it, and then built features to move those metrics.
Working on some projects that end up failing is perfectly normal. What's important is to front-load as much of the risk as possible and to be explicit about the hypotheses required to make a project successful so that you can validate them early and, if necessary, change course.
That's where some of the projects we worked on at Quora failed (e.g. topic groups, an infrastructure rewrite) -- we let ourselves be overly confident about what we knew and didn't invest the time to sanity check our hypotheses.
For my book, validation played a huge role. Even before I started writing my book, I had written engineering-related answers on Quora for over two years and started to get a sense of what resonated with readers. That helped me build confidence that there would be demand for something in this space. Continued feedback and reviews during the writing process built on that confidence more.
In some sense, it might actually be easier to tell at a startup because what matters at a startup is growth. That can be growth of revenue (if you already have a product to sell) or growth of users (if you need traffic first to sell, e.g. Quora).
The highest-leverage work would then be the things that most directly lead to that growth. Sometimes, this will require talking with product managers or salespeople or users to understand what the biggest accelerators or roadblocks would be. So, for example, at Quip, I looked at data on how the product spread within teams and organizations, developed engagement metrics around it, and then built features to move those metrics.
Working on some projects that end up failing is perfectly normal. What's important is to front-load as much of the risk as possible and to be explicit about the hypotheses required to make a project successful so that you can validate them early and, if necessary, change course.
That's where some of the projects we worked on at Quora failed (e.g. topic groups, an infrastructure rewrite) -- we let ourselves be overly confident about what we knew and didn't invest the time to sanity check our hypotheses.
For my book, validation played a huge role. Even before I started writing my book, I had written engineering-related answers on Quora for over two years and started to get a sense of what resonated with readers. That helped me build confidence that there would be demand for something in this space. Continued feedback and reviews during the writing process built on that confidence more.
Would be interesting to hear more about the projects that failed. How big of a rewrite was it? How long did it take before the group or a manager recognized that the project was failing? How did the group deal with the failure in the social sense?
Any tips on getting buy in to things like this, where the CEO would be on board but middle management would not prioritize it?
Have you read much Drucker? You cover some of the same ideas.
Yep! I've read The Effective Executive. One of my big motivators for writing the book was that there were all these great ideas that were encapsulated in business books or personal improvement books, and very few books that would tie them back to engineering. That's the gap I wanted to fill.
Great. Though one of the complaints I have here is the same I have with Drucker, and the same that others have given: "Impact" is ill defined.
Your observation is a key reason why taking the time to define your impact and to measure it is so important. As Drucker says, what gets measured gets improved.
In business contexts, your engineering impact generally ties back to the business value you create (i.e. revenue and profit). If there is already some model for translating your area of work to revenue (e.g. increase users -> increase revenue, reduce fraud -> increase revenue) then that can also give another proxy metric to optimize for. So for example, when working on Google Search Quality, we would often just optimize for long clickthrough rates, knowing that strategically, the ads team would take care of turning returning searchers to revenue.
It gets harder when you're working on areas like bigger bets (where you can have high impact but it is unknown for a long time) or in trying to understand an infrastructure investment in terms of its business value to the company. There, it may be sufficient to just know that something is of strategic value and then measure your impact in terms of those strategic goals.
In business contexts, your engineering impact generally ties back to the business value you create (i.e. revenue and profit). If there is already some model for translating your area of work to revenue (e.g. increase users -> increase revenue, reduce fraud -> increase revenue) then that can also give another proxy metric to optimize for. So for example, when working on Google Search Quality, we would often just optimize for long clickthrough rates, knowing that strategically, the ads team would take care of turning returning searchers to revenue.
It gets harder when you're working on areas like bigger bets (where you can have high impact but it is unknown for a long time) or in trying to understand an infrastructure investment in terms of its business value to the company. There, it may be sufficient to just know that something is of strategic value and then measure your impact in terms of those strategic goals.
What was the process like? How much time did you spend relative to other projects, and how did you incorporate your principles of leverage into creating the book?
In many ways, it was similar to building a startup product.
I quit my full-time job at Quora and spent ten months full-time on the book (with bits of traveling). Like any other project, I drastically estimated how long it would take. I estimated one year; it ended up taking almost two. I finished the book while working full-time at Quip.
At times, it was an amazing adventure. I loved going around Silicon Valley and interviewing people like Mike Krieger or Sam Schillace to get their stories and their most valuable lessons.
Other times, there were also intense periods of self-doubt. The first person I shared a chapter draft with was my wife. She's also an engineer and by default can give quite critical feedback. And, wow, did I feel shut down after my first round of feedback. It's confusing! I don't understand the point of this! etc.
I ended up spending two months iterating by myself on my next drafts to build up more confidence before sharing with more engineering friends -- they then really gave me the support I needed to feel confident about writing the book. The experience was a great lesson in how new ideas need to be nurtured, and you need to either find supporters who will nurture that for you, or ask for the type of feedback you want (which is what I now do with my wife). It was also a valuable lesson in getting feedback sooner on your project before you are too emotionally attached to feel comfortable about asking for feedback.
All in all, it's one of my proudest accomplishments in my career.
I quit my full-time job at Quora and spent ten months full-time on the book (with bits of traveling). Like any other project, I drastically estimated how long it would take. I estimated one year; it ended up taking almost two. I finished the book while working full-time at Quip.
At times, it was an amazing adventure. I loved going around Silicon Valley and interviewing people like Mike Krieger or Sam Schillace to get their stories and their most valuable lessons.
Other times, there were also intense periods of self-doubt. The first person I shared a chapter draft with was my wife. She's also an engineer and by default can give quite critical feedback. And, wow, did I feel shut down after my first round of feedback. It's confusing! I don't understand the point of this! etc.
I ended up spending two months iterating by myself on my next drafts to build up more confidence before sharing with more engineering friends -- they then really gave me the support I needed to feel confident about writing the book. The experience was a great lesson in how new ideas need to be nurtured, and you need to either find supporters who will nurture that for you, or ask for the type of feedback you want (which is what I now do with my wife). It was also a valuable lesson in getting feedback sooner on your project before you are too emotionally attached to feel comfortable about asking for feedback.
All in all, it's one of my proudest accomplishments in my career.
I also just remembered that I wrote this blog post a while back on what self-publishing taught me about shipping products. It also shares a few vignettes and lessons from my self-publishing experience.
http://www.effectiveengineer.com/blog/lessons-from-self-publ...
http://www.effectiveengineer.com/blog/lessons-from-self-publ...
It's strange how obsessed software engineers are about methods of working. At a surface level it's just: sit down and write the code. But actually there are thousands of programming languages you can choose from; there are build tools, code standards, testing(to TDD or not to TDD) and mental models you have to wrap your head around before you even can start to consider yourself a decent programmer. It's fascinating, but at the same time I wish it was all simpler. I wonder if there are other occupations in the world that are so much focused on tools, paradigms and methodology as software engineering(investing and trading come in mind. And it's interesting that these notes use so much investing and business lingo).
It's strange how obsessed software engineers are about methods of working.
So you are surprised that a bunch of people whose work is to create mental models and automate them are obsessed with creating mental models of their own work and automate it?
It's fascinating, but at the same time I wish it was all simpler.
Actually it is, IMHO. A lot of the parafernalia around the job is useless obsession indeed. We're just that way for good or bad.
So you are surprised that a bunch of people whose work is to create mental models and automate them are obsessed with creating mental models of their own work and automate it?
It's fascinating, but at the same time I wish it was all simpler.
Actually it is, IMHO. A lot of the parafernalia around the job is useless obsession indeed. We're just that way for good or bad.
Many medical devices and advances in procedure are invented by doctors.
If it was simpler, it wont command such wages, and would be automated out sooner.
Humans' current advantage is the ability to tackle complexity and uncertainty.
Humans' current advantage is the ability to tackle complexity and uncertainty.
I think the comment you're replying to is implicitly making the point that some of the complexity is manufactured and needless.
Another way to look at it is automation will free people up to solve more important problems.
Yes, those who'll happen to be capable of that by the time.
Business process improvement is similar.
On the topic of reading code “written by brilliant engineers”…
Code bases can be so large that you might find brilliantly-written things intermixed with things that are not brilliant (and some of those parts may even have been added by the brilliant engineer on an off day). Therefore, it’s risky to just absorb an entire blob as Good without also understanding its history.
An interesting side effect of languages/ecosystems with single coding styles enforced: bad changes to good code no longer stick out like a sore thumb! In my experience, developers with the discipline to write great code also typically write it in a consistently structured way, and it’s kind of useful that “warts” added by others over time usually won’t follow the structure/style and those warts will be easier to find and scrutinize.
Code bases can be so large that you might find brilliantly-written things intermixed with things that are not brilliant (and some of those parts may even have been added by the brilliant engineer on an off day). Therefore, it’s risky to just absorb an entire blob as Good without also understanding its history.
An interesting side effect of languages/ecosystems with single coding styles enforced: bad changes to good code no longer stick out like a sore thumb! In my experience, developers with the discipline to write great code also typically write it in a consistently structured way, and it’s kind of useful that “warts” added by others over time usually won’t follow the structure/style and those warts will be easier to find and scrutinize.
Somewhat unrelated, it would be great to have a Medium-style highlight feature for codebases, where you could onboard developers toward excellent practice by highlighting good code in a repository that consists of various levels of code.
That's actually a really brilliant idea.
We have people sometimes produce the software equivalent of a Picasso, but it so rarely comes to light, and even more rarely codified to guidelines/standard-practice.
Would be very good to have "greatest-hits" of a company's codebase, that could serve as internal knowledge-sharing.
We have people sometimes produce the software equivalent of a Picasso, but it so rarely comes to light, and even more rarely codified to guidelines/standard-practice.
Would be very good to have "greatest-hits" of a company's codebase, that could serve as internal knowledge-sharing.
Like this?
https://github.com/github/hub/blob/master/github/crash_repor...
Or do you mean with comments in the margin?
https://github.com/github/hub/blob/master/github/crash_repor...
Or do you mean with comments in the margin?
> coding styles enforced: bad changes to good code no longer stick out like a sore thumb!
I can see the benefit of being able to identify smelly code immediately from poor code structure. However, I think that coding styles enforce consistency between good programmers who maintain their own coding style. A reviewer should be able to discern code quality - even with compliant code style - by how quickly it is to comprehend.
I can see the benefit of being able to identify smelly code immediately from poor code structure. However, I think that coding styles enforce consistency between good programmers who maintain their own coding style. A reviewer should be able to discern code quality - even with compliant code style - by how quickly it is to comprehend.
People often don't realise the person who improved the codebase within a short span of time had years of experience in the domain. I know a class of engineers who are solving the EXACT same problem using the EXACT same method from from company to company. To someone from outside, it might appear like they are job hopping looking at their average time spent at a company.
The effect can't last long though: The long-surviving codebase becomes such a mix of styles that it's more noise than signal, and even the good code appears as just another local inconsistency.
> Optimize for Learning
An idealist, for sure...
> Prioritize learning over profitability.
... but that doesn't sound very pragmatic.
I love learning. My boss loves making the company profitable. Coming to a happy medium is where a lot of learning can happen if both of you let it. If one party's not on board, then it's going to end up being a problem.
An idealist, for sure...
> Prioritize learning over profitability.
... but that doesn't sound very pragmatic.
I love learning. My boss loves making the company profitable. Coming to a happy medium is where a lot of learning can happen if both of you let it. If one party's not on board, then it's going to end up being a problem.
I really liked this post, and I'm again saddened to see 'take downs' in the comments (not solely addressing you).
The author said "prioritize" not to sacrifice profitability in order to learn. By prioritizing learning you may very well increase profitability over the long term. See the recent Google Maps is a moat post.
The author said "prioritize" not to sacrifice profitability in order to learn. By prioritizing learning you may very well increase profitability over the long term. See the recent Google Maps is a moat post.
Challenging an idea is not a "take down".
At the time I posted there were 3 top level comments, all negative on the post.
> ... If one party's not on board, then it's going to end up being a problem.
Idealism, IMHO, acts as a motivator and helps folks get through the obstacles that inevitably block progress.
romanovcode(2)
I think that the understanding of software engineering as an occupation is a bit oversimplified.
While there are good chances most people will be working on web or mobile applications, there's much more going on. Compilers, cryptography, compression, operating systems, graphics, simulation, data retrieval, distributed systems, etc. To that you need to add machine learning and AI.
I think it is hard to come up with a unified set of tactics/strategy to be an effective engineer at each part of this occupational spectrum.
For example, some engineers, while learning, try to specialize themselves in an area while others try to become generalists. Both approaches can be valid depending on the role.
Some engineers focus on applied science while others on theoretical science, some others just on empirical knowledge, processes and techniques. Again, the impact of this decision will largely depend on the role.
Then, prioritization is a double edged sword. To do what is perceived as important is intuitively the right thing to do. But during learning it is harder to recognize what is important. This is how many people end up neglecting valuable learning.
While there are good chances most people will be working on web or mobile applications, there's much more going on. Compilers, cryptography, compression, operating systems, graphics, simulation, data retrieval, distributed systems, etc. To that you need to add machine learning and AI.
I think it is hard to come up with a unified set of tactics/strategy to be an effective engineer at each part of this occupational spectrum.
For example, some engineers, while learning, try to specialize themselves in an area while others try to become generalists. Both approaches can be valid depending on the role.
Some engineers focus on applied science while others on theoretical science, some others just on empirical knowledge, processes and techniques. Again, the impact of this decision will largely depend on the role.
Then, prioritization is a double edged sword. To do what is perceived as important is intuitively the right thing to do. But during learning it is harder to recognize what is important. This is how many people end up neglecting valuable learning.
Pretty good overview, although I was aghast when I saw that The Mythical Man Month was missing from the book list. The Effective Executive is also a timeless classic that's useful to anyone who manages anything.
It references the primary concept, and it also looks like much of the information from MMM is already distilled into this - which is not hard to do; MMM is a bit verbose if I recall correctly.
I love all of Edmond Lau's stuff. I accidentally found one of his Google talks while trying to find something for my team when we started on fixing a massively underscaled tech stack. I bought the book read it and shared it with a few other engineers. Super valuable and a lesson I keep trying to teach to our organization is how worth it is to build better tooling.
Thank you! It means a lot to me hear its impact on you -- stories from readers are what keep me excited about doing this work.
(From the gist's account owner)
FWIW: I didn't produce the content present on this gist.
I've just copy-pasted it from somewhere over the Internet, but I cannot remember exactly the original source. I was also not able to find the author's name, so I cannot give him/her the proper credit.
FWIW: I didn't produce the content present on this gist.
I've just copy-pasted it from somewhere over the Internet, but I cannot remember exactly the original source. I was also not able to find the author's name, so I cannot give him/her the proper credit.
This seems like something worth mentioning on the gist.
Lot of very selfish anti team ideas here. Shipping requires doing grunt work. That’s the person I want to work with and that’s the person I think is valuable.
Perhaps I misread the post. I thought there were several points about putting your team first.
I've found that this can mean doing grunt work or it can mean reducing siloed information by having them do grunt work. This is to say that helping the team, helping grow yourself, and helping to ship product are not mutually exclusive from each other.
I've found that this can mean doing grunt work or it can mean reducing siloed information by having them do grunt work. This is to say that helping the team, helping grow yourself, and helping to ship product are not mutually exclusive from each other.
Name the things in the list that are anti-team or selfish, or avoid grunt-work. Being more productive would seem to benefit your team, no?
I work on a team in which a few people adopted the strategy of doing 20% of the work for 80% of the impact. That leaves the rest of us doing the remaining 80%. If the people doing most of the work are not getting the credit for it, how is it going to play out in the long run?
Why does that 80% need to be done?
How else do you get to 100% of the work done?
What I mean is that the number of pieces of work that can be done is some high multiple of the work that you can do. So find the projects that are in the top 20% of impact by starting with “why does this need to happen?”
Of course if someone is only doing 20% of any given piece of work (say, never writing tests or refactoring or doing code review), then yea, that is a big problem.
Of course if someone is only doing 20% of any given piece of work (say, never writing tests or refactoring or doing code review), then yea, that is a big problem.
Hang on.. What should I do first?
+ The most valuable thing? + The riskiest thing? + The simple thing?
+ The most valuable thing? + The riskiest thing? + The simple thing?
They're orthogonal dimensions. My fault that this isn't clearer.
Here's a simpler ordering of operations:
1. Start with the most valuable, highest-leverage thing you want to focus on. 2. Figure out what the riskiest bit of that thing is. Focus on de-risking it. 3. When you're de-risking (or more generally whenever you're just doing that thing), start simple. Beware of adding in unnecessary complexity.
Here's a simpler ordering of operations:
1. Start with the most valuable, highest-leverage thing you want to focus on. 2. Figure out what the riskiest bit of that thing is. Focus on de-risking it. 3. When you're de-risking (or more generally whenever you're just doing that thing), start simple. Beware of adding in unnecessary complexity.
You should work first on the riskiest part of the [guesstimated] most valuable thing.
Edit: [guesstimated]
Edit: [guesstimated]
High leverage, compounding learning, exponential growth, high impact work, high priority, fast paced, focus on value, larger time blocks, ever deeper flow, prioritization for higher leverage, faster deployment, faster tools, shorter iterations, skyrocketing productivity, scale impact beyond confines, impact scaling, time saving, shorter loops, faster tests, shorter compiles, mastered tools...
Does any of this seem a bit Shepard Tones to anyone else?
https://www.youtube.com/watch?v=OsBanpBQj0k
(ever-ascending-tones audio illusion)
Does any of this seem a bit Shepard Tones to anyone else?
https://www.youtube.com/watch?v=OsBanpBQj0k
(ever-ascending-tones audio illusion)
My most useful insight/takeaway from the book was about leverage and what activities you choose to do as you progress in your career: in six months you could ship 1x engineers worth of output (or maybe 2x or 3x if you are really great) -- or you could help hire and onboard 10 engineers and create 10x worth of output.
Thinking more strategically about the most effective way to spend my own time and energy was easily worth the nominal cost of the book.
Thinking more strategically about the most effective way to spend my own time and energy was easily worth the nominal cost of the book.
A combination of software engineering and domain expertise makes for a really effective engineer.
As an example - if you work as an software engineer in finance learn about a few particular financial products at the same level or better than your users, get a masters in finance, applied math, accounting and whatnot. This has the added benefit of staying relevant in the market when you age, as software engineering becomes increasingly commoditized.
As an example - if you work as an software engineer in finance learn about a few particular financial products at the same level or better than your users, get a masters in finance, applied math, accounting and whatnot. This has the added benefit of staying relevant in the market when you age, as software engineering becomes increasingly commoditized.
This is effective nonsense. Based on my personal experience, effective engineers I know do not follow a formula like this.
This looks like a list of how to be teacher’s pet. A superficial need to be praised by others as effective only takes to “mediocre”.
This looks like a list of how to be teacher’s pet. A superficial need to be praised by others as effective only takes to “mediocre”.
Perhaps rather than spew vacuous insults, you could describe specifically how effective engineers differ from the descriptions in this post.
You may want to read the due diligence I did about this topic. https://news.ycombinator.com/item?id=16037746
One other quality of effective engineers is not fall for bullshit and have a scientific mindset of inquiry.
One other quality of effective engineers is not fall for bullshit and have a scientific mindset of inquiry.
What do effective engineers do then? Based on your experience, what practices do they implement?
Please read more research i did here about this content.
https://news.ycombinator.com/item?id=16037746
You decide if there is any merit to the advice given.
https://news.ycombinator.com/item?id=16037746
You decide if there is any merit to the advice given.
There are good ways and bad ways to interpret the book. Just because good engineers have historically not lived their lives according to these particular buzzwords, does not mean they haven't implicitly incorperated similar, analogous, strategies. I would be surprised if Linus Torvalds and Peter Norvig and the like didn't use concepts like prioritization, investing in tools, and some similar idea (though not necessarily expressed in that way) to the 80/20 rule. Why should it matter from which culture productivity buzzwords originate from?
Also it comes off as a way to build a career at the companys expense.
You're forgetting the fact that the company is also building it's "career" off your's too.
Don't believe me? Any invention that you have created at your workplace (patents etc.) is always held by your company, not you.
Don't believe me? Any invention that you have created at your workplace (patents etc.) is always held by your company, not you.
That's the deal though isn't it?
They pay me real money - I do real work for them.
They pay me real money - I do real work for them.
You expend labour; they build capital. The capital you build produces returns long into the future, but you don't own any of that future income stream. Sooner or later, your sharpness and skills will decline, and your labour will be relatively worthless. The capital you helped build will continue to be valuable (presuming you did a good job).
It's a poor deal if you're in a competitive market where there's another schmuck willing to do your job for just as cheap as you do it. But if you have pricing power, you'd be a complete fool not to either charge substantially more, or demand some ownership.
It's a poor deal if you're in a competitive market where there's another schmuck willing to do your job for just as cheap as you do it. But if you have pricing power, you'd be a complete fool not to either charge substantially more, or demand some ownership.
So you're okay with the fact that they are kinda-sorta exploiting you (by not including you as a co-patent holder) but have reservations on employees utilizing company resources to further their career?
That seems like a really raw deal to me. You might argue that you are "paid" to do this; not really, you can just coast on 9-5 and draw the same (or in the same ballpark) paycheck as someone who is busting his behind to invent something. Also when there is downsizing you might think that contributions is the only thing that matters, but it is demonstrably not (I'm speaking about regular companies not a small startup).
That seems like a really raw deal to me. You might argue that you are "paid" to do this; not really, you can just coast on 9-5 and draw the same (or in the same ballpark) paycheck as someone who is busting his behind to invent something. Also when there is downsizing you might think that contributions is the only thing that matters, but it is demonstrably not (I'm speaking about regular companies not a small startup).
Which parts hurt the company?
What do effective engineers do then?
read the background verification i did for the same
https://news.ycombinator.com/item?id=16037746
https://news.ycombinator.com/item?id=16037746
I will try to elaborate without trying to insult anyone. It might be harsh but I am sure the author can handle it.
First of all look at this sales copy of the book. https://www.effectiveengineer.com/book
It looks like a weight loss e-book product designed to trick ambitious people into impulse buying. It tries to build credibility by name dropping "google", "facebook", "insert big company here" every other paragraph. Then there are testimonials about how great the advice is from "LeaderLeaderLeader" enterprise hierarchy pattern i.e people with big titles from popular silicon valley companies.
Everything in that page is designed and optimized to make you buy the package. For a price of 250$ you too can know the secrets of effective Engineers.
To sell this content first create and exploit an insecurity in jr.Engineers or fresh job seekers in technology by saying they are not an effective engineer unless they buy this book/package and read the content and then they too will be part of the club and work at a big name brand company. Some people in our work places are exceptionally good at social engineering and not so much in actual engineering. The sales copy co-opted the "engineering" discipline to sell some curated content. This looks much similar to team/company "politics".
I do not think people in "effective engineering" business do this. This is certainly what people in content business do.
Now compare that to some other book for a contrast. https://basecamp.com/books/getting-real
Engineering is just like any other skill for e.g., like playing chess or piano or swimming etc. You get better by doing it many times and failing often. To be good at engineering involves many factors like genetics, discipline, irrational love and passion for a particular domain, patience, exposure to better ideas and better people. Even you are good at engineering, to be effective at a company/market, you need to know the right people and have right social and financial skills to get name and recognition.
Some how, effective engineering has become synonymous with what happens at big name company teams which I think is very wrong. If you look at the real world, once companies reach a bigger size, they stop doing effective anything. They just buy other small companies which spend more time on making effective products.
This content seems to be analogous to "founders at work" but a better title would have been "engineers at the enterprise".
First of all look at this sales copy of the book. https://www.effectiveengineer.com/book
It looks like a weight loss e-book product designed to trick ambitious people into impulse buying. It tries to build credibility by name dropping "google", "facebook", "insert big company here" every other paragraph. Then there are testimonials about how great the advice is from "LeaderLeaderLeader" enterprise hierarchy pattern i.e people with big titles from popular silicon valley companies.
Everything in that page is designed and optimized to make you buy the package. For a price of 250$ you too can know the secrets of effective Engineers.
To sell this content first create and exploit an insecurity in jr.Engineers or fresh job seekers in technology by saying they are not an effective engineer unless they buy this book/package and read the content and then they too will be part of the club and work at a big name brand company. Some people in our work places are exceptionally good at social engineering and not so much in actual engineering. The sales copy co-opted the "engineering" discipline to sell some curated content. This looks much similar to team/company "politics".
I do not think people in "effective engineering" business do this. This is certainly what people in content business do.
Now compare that to some other book for a contrast. https://basecamp.com/books/getting-real
Engineering is just like any other skill for e.g., like playing chess or piano or swimming etc. You get better by doing it many times and failing often. To be good at engineering involves many factors like genetics, discipline, irrational love and passion for a particular domain, patience, exposure to better ideas and better people. Even you are good at engineering, to be effective at a company/market, you need to know the right people and have right social and financial skills to get name and recognition.
Some how, effective engineering has become synonymous with what happens at big name company teams which I think is very wrong. If you look at the real world, once companies reach a bigger size, they stop doing effective anything. They just buy other small companies which spend more time on making effective products.
This content seems to be analogous to "founders at work" but a better title would have been "engineers at the enterprise".
The perspective I'll offer is that good sales copy is also a skill, just like engineering or any of the other skills you mention.
To be good at sales copy also involves many factors, like interviewing your prospective customers, understanding what language they use to describe their problems, listening for what dreams they actually have, addressing their concerns by establishing credibility, and having a strong desire to help them achieve their goals.
Good sales copy doesn't aim to "trick" people; it aims to show that the product being sold will achieve the prospective customer's goals.
The reason I'm sharing this perspective is that many engineers do look down on marketing and sales copy as something that's automatically "bad." And that automatic association does them a disservice.
They write awesome code or build awesome products and features that could add so much value to the world, but they then just expect anyone to automatically see that value. They don't take the time to understand what their users' problems might be, to share how what they built might solve those problems, and to "market" their solutions. That mismatch of supply and demand ends up being a missed opportunity, and sadly, this happens all the time.
To be good at sales copy also involves many factors, like interviewing your prospective customers, understanding what language they use to describe their problems, listening for what dreams they actually have, addressing their concerns by establishing credibility, and having a strong desire to help them achieve their goals.
Good sales copy doesn't aim to "trick" people; it aims to show that the product being sold will achieve the prospective customer's goals.
The reason I'm sharing this perspective is that many engineers do look down on marketing and sales copy as something that's automatically "bad." And that automatic association does them a disservice.
They write awesome code or build awesome products and features that could add so much value to the world, but they then just expect anyone to automatically see that value. They don't take the time to understand what their users' problems might be, to share how what they built might solve those problems, and to "market" their solutions. That mismatch of supply and demand ends up being a missed opportunity, and sadly, this happens all the time.
Hope what ever you did works for you. I am probably not your prospective customer. I found the whole sales copy very deceptive. You are selling "Tactical Toolkit" to be effective engineer.
I understand your perspective about engineers undervaluing marketing and sales skills, but I think it's an example of short term thinking. Credibility is a currency, internet never forgets and I would never build credibility like this because I do not know how this will limit my future possibilities.
I understand your perspective about engineers undervaluing marketing and sales skills, but I think it's an example of short term thinking. Credibility is a currency, internet never forgets and I would never build credibility like this because I do not know how this will limit my future possibilities.
You seem to be criticizing mostly how the book is marketed as opposed to its actual content. And I will agree with you, this page is awful, and it absolutely reads like the typical "get rich in 2 weeks" scam. But the content as described in this gist is interesting.
Do you disagree that effective engineers need to come up with strategies to be continuously learning? Or that it's important to make sure you spend time on tasks/projects that matter as opposed to busy-work? Or that it's important to properly use your daily tools? etc etc
I haven't read the book, and I only went over the main headers of this gist, but this all looks like pretty sensible advice to me to be more effective and productive.
Do you disagree that effective engineers need to come up with strategies to be continuously learning? Or that it's important to make sure you spend time on tasks/projects that matter as opposed to busy-work? Or that it's important to properly use your daily tools? etc etc
I haven't read the book, and I only went over the main headers of this gist, but this all looks like pretty sensible advice to me to be more effective and productive.
I'd say you don't seem to understand what makes an effective engineer. You ignore the benefits of introspection and discount the ability to improve yourself. Good habits can be cultivated. A career can be cultivated, any good engineer can target better jobs to move up step by step where they want to be.
The author is just giving you advice for doing those things.
The author is just giving you advice for doing those things.
You may be right. Only the people who bought that “tactical toolkit” from that sales page are effective engineers. Everyone else may just not be up to it.
We used to call engineers who do tasks that elevate themselves at the expense of rest of the team as bad team players. Now the advice here is to do high leverage tasks.
The whole premise of the content appears to be a “get rich quick” scheme. The most vulnerable people in the industry are the young people looking for guidance and advice from older generations. The sales copy is clearly exploiting their insecurity by suggesting somehow there is a shortcut and by knowing these secrets for a small price, you too can be a 10x engineer.
We used to call engineers who do tasks that elevate themselves at the expense of rest of the team as bad team players. Now the advice here is to do high leverage tasks.
The whole premise of the content appears to be a “get rich quick” scheme. The most vulnerable people in the industry are the young people looking for guidance and advice from older generations. The sales copy is clearly exploiting their insecurity by suggesting somehow there is a shortcut and by knowing these secrets for a small price, you too can be a 10x engineer.
Wow. The author really pissed your cornflakes, didn’t he? I’ve been an engineer for 30 years, this is the first i’ve heard of author or his book, but i have to say i agree with much of his advice.
When you have a choice, you should always choose high leverage. You should work to limit distractions and get more focus time. This is all great advice.
When you have a choice, you should always choose high leverage. You should work to limit distractions and get more focus time. This is all great advice.
I see what you are trying to do here. But please go read the sales copy of the book. Everything in that copy is a symptom of "moral decay" in the tech valley.
Which one did you purchase? "The master package" to become effective engineer.
It makes bold claims like it will make you 10X engineer and it some how guides you to figure out which technologies you need to work that will succeed in the future and keep reading, you will find more gems in there. The whole content is preying on the vulnerable.
We have had great advice in the tech industry so far like, "put customer first" or "think lean" or build beautiful products etc but this is the first classic that says to put yourself first and work on things that elevate you at the expense of the team and company and more narcissistic gems bundled with gossip from engineering teams with famous name companies.
I seriously doubt anyone who is looked upon for guidance by others would suggest something like this.
adios while I read the "Tactial Toolkit" to become effective engineer.
Which one did you purchase? "The master package" to become effective engineer.
It makes bold claims like it will make you 10X engineer and it some how guides you to figure out which technologies you need to work that will succeed in the future and keep reading, you will find more gems in there. The whole content is preying on the vulnerable.
We have had great advice in the tech industry so far like, "put customer first" or "think lean" or build beautiful products etc but this is the first classic that says to put yourself first and work on things that elevate you at the expense of the team and company and more narcissistic gems bundled with gossip from engineering teams with famous name companies.
I seriously doubt anyone who is looked upon for guidance by others would suggest something like this.
adios while I read the "Tactial Toolkit" to become effective engineer.
I haven’t paid the author a dime, but did just sign up to get the free chapter of the book, i recommend you read it because it’s his actual advice. My review was it’s pretty good, a bit rushed/compressed, but his advice is very straightforward and all focused on getting more and better work done for your company, how much more team oriented does it get than that?
BTW i didn’t see any marketing claim on his site that he’ll magically turn you into a 10x developer, but googling found this blog. Read it and try to tell me it’s advice isn’t good or that it’s “corrosive” in any way to the team.
http://www.effectiveengineer.com/blog/how-to-become-a-10x-en...
BTW i didn’t see any marketing claim on his site that he’ll magically turn you into a 10x developer, but googling found this blog. Read it and try to tell me it’s advice isn’t good or that it’s “corrosive” in any way to the team.
http://www.effectiveengineer.com/blog/how-to-become-a-10x-en...
Ok I will engage in this conversation.
First let me look up the author. Let me also just say that I have nothing against this author. I respect his entrepreneurial spirit and I believe he has a great future. But I deeply believe this sales page here is just plain wrong https://www.effectiveengineer.com/book and I strongly feel that experienced people like myself have to speak up when situation calls for it. It is fundamentally sleazy thing to do to other younger minds seeking proper guidance in the tech valley.
Authors resume
https://angel.co/edmondlau
First things I noticed. This person has not stayed at any company for more than 3 years. No strong engineering role titles like architecture or design or scaling roles. Mostly soft engineering roles like testing and growth hacking. as a 30 year experienced person like yourself ask yourself. What kind of serious engineering product can one build in that time period at a company with that roles and how many? In many respectable companies I worked for, a person with this experience level cannot even hire/fire people, interviewing someone is not same as hiring.
Next look at the the github profile vs quora profile.
https://github.com/edmondlau
https://www.quora.com/profile/Edmond-Lau
You can notice, this person is more of a content writer compared to code writer. What sort of engineering skills and expertise do you notice about the author that makes him write a sales page like this?.
https://www.effectiveengineer.com/book
Just like how I said it before, this is an effective nonsense garbage content marketing. The author has no qualifications to be writing a book on effective engineering. It is an insult to people who do actual engineering.
This person is milking his past job experience role at brand name companies to an irresponsible extent. This is not illegal but a very sleazy thing to do.
To people who really care about this topic, please get a good mentor in and around your workplace. Just do not fall for this click baits and gossip about tech companies does not make you effective anything. Engineering skill takes a lot of practice and patience, I am afraid there are no secrets and shortcuts.
First let me look up the author. Let me also just say that I have nothing against this author. I respect his entrepreneurial spirit and I believe he has a great future. But I deeply believe this sales page here is just plain wrong https://www.effectiveengineer.com/book and I strongly feel that experienced people like myself have to speak up when situation calls for it. It is fundamentally sleazy thing to do to other younger minds seeking proper guidance in the tech valley.
Authors resume
https://angel.co/edmondlau
First things I noticed. This person has not stayed at any company for more than 3 years. No strong engineering role titles like architecture or design or scaling roles. Mostly soft engineering roles like testing and growth hacking. as a 30 year experienced person like yourself ask yourself. What kind of serious engineering product can one build in that time period at a company with that roles and how many? In many respectable companies I worked for, a person with this experience level cannot even hire/fire people, interviewing someone is not same as hiring.
Next look at the the github profile vs quora profile.
https://github.com/edmondlau
https://www.quora.com/profile/Edmond-Lau
You can notice, this person is more of a content writer compared to code writer. What sort of engineering skills and expertise do you notice about the author that makes him write a sales page like this?.
https://www.effectiveengineer.com/book
Just like how I said it before, this is an effective nonsense garbage content marketing. The author has no qualifications to be writing a book on effective engineering. It is an insult to people who do actual engineering.
This person is milking his past job experience role at brand name companies to an irresponsible extent. This is not illegal but a very sleazy thing to do.
To people who really care about this topic, please get a good mentor in and around your workplace. Just do not fall for this click baits and gossip about tech companies does not make you effective anything. Engineering skill takes a lot of practice and patience, I am afraid there are no secrets and shortcuts.
Your entire argument is just a thinly sourced (anti)appeal to authority argument. You can’t sum up a persons life experience from a short bio and their github history (most of mine is private for example)
If you don’t like specific ideas of his, attack them. But as a 30 year engineer whose managed teams as large as 40 people, while i don’t agree with everything he wrote, lots of it rings true to me.
If you don’t like specific ideas of his, attack them. But as a 30 year engineer whose managed teams as large as 40 people, while i don’t agree with everything he wrote, lots of it rings true to me.
That short bio has no qualifications enough to write a book on effective engineering especially making claims like guiding people to become 10x engineer.
I find it difficult for a person with valid credentials in real life support this content marketing fraud.
I find it difficult for a person with valid credentials in real life support this content marketing fraud.
> We used to call engineers who do tasks that elevate themselves at the expense of rest of the team as bad team players. Now the advice here is to do high leverage tasks.
You haven't even read the notes, if you're conflating these two ideas.
You haven't even read the notes, if you're conflating these two ideas.
> To sell this content first create and exploit an insecurity in jr.Engineers or fresh job seekers in technology by saying they are not an effective engineer unless they buy this book/package
Where are you reading this?
Where are you reading this?
Read the sales copy. I just copied the first few lines of the first paragraph.
"The most effective engineers — the ones who have risen to become distinguished engineers and leaders at their companies — can produce 10 times the impact of other engineers, but they're not working 10 times the hours."
Taken from https://www.effectiveengineer.com/book
"The most effective engineers — the ones who have risen to become distinguished engineers and leaders at their companies — can produce 10 times the impact of other engineers, but they're not working 10 times the hours."
Taken from https://www.effectiveengineer.com/book
That doesn't imply what you claimed at all.
lazyasciiart(2)
Care to suggest better ways?
I did a background check and things do not add up for me.
https://news.ycombinator.com/item?id=16037746
https://news.ycombinator.com/item?id=16037746
On the "read code written by brilliant engineers" point, as someone just starting to learn Python, where would I find some?
If there are engineers you highly respect on your team, their code is a great place to start.
Otherwise, many top tech companies now open source software that they've written internally, oftentimes with their own websites. And there is also a growing trend for them to actually maintain the software they open source as opposed to just throwing it over the fence.
Think of companies that have a strong engineering brand, and then just search for what open source software they're released. Pick whatever seems most aligned with your interests.
Some examples:
Google: https://opensource.google.com/projects/list/featured?languag... Facebook: https://code.facebook.com/projects/#backend Stripe: https://stripe.com/open-source Airbnb: http://airbnb.io/projects/
Otherwise, many top tech companies now open source software that they've written internally, oftentimes with their own websites. And there is also a growing trend for them to actually maintain the software they open source as opposed to just throwing it over the fence.
Think of companies that have a strong engineering brand, and then just search for what open source software they're released. Pick whatever seems most aligned with your interests.
Some examples:
Google: https://opensource.google.com/projects/list/featured?languag... Facebook: https://code.facebook.com/projects/#backend Stripe: https://stripe.com/open-source Airbnb: http://airbnb.io/projects/
Lots of different ways:
- Find a function call you're making in a library and see how it works
- Look through the top python libraries (see https://github.com/vinta/awesome-python ) and pick a few of the simpler ones to flip through
For reading code, some things that can be useful:
- Flip through test suite and get tests running; then break some tests to see what's happening
- Diagram out code on a piece of paper (file structure, data structure, stack trace for a popular call)
- Discuss implementation with friends
- For certain files, it's often valuable to rewrite yourself
- Find a function call you're making in a library and see how it works
- Look through the top python libraries (see https://github.com/vinta/awesome-python ) and pick a few of the simpler ones to flip through
For reading code, some things that can be useful:
- Flip through test suite and get tests running; then break some tests to see what's happening
- Diagram out code on a piece of paper (file structure, data structure, stack trace for a popular call)
- Discuss implementation with friends
- For certain files, it's often valuable to rewrite yourself
Peter Norvig has lots of expository code that embodies lots of good design.
I find I like to learn the flavor of different kinds of code, but practical codebases have so much stuff going on that it's not easy to find the distinctive part. It would be great to see more people do expository versions of familiar software and libraries.
I find I like to learn the flavor of different kinds of code, but practical codebases have so much stuff going on that it's not easy to find the distinctive part. It would be great to see more people do expository versions of familiar software and libraries.
+1 Here's a link to Norvig's (self annotated!) github repo: https://github.com/norvig/pytudes
Reading code is the equivalent of looking at solutions for math problems... is it more helpful reading the solutions without context or with? You need to see the original problem, and how the solution came about in response to that problem. In regard to this, I would say, pick a problem that has a solution (walkthrough, if possible) available and then attempt to solve it and then honestly check your solution against the given solution.
Anything written by Kenneth Reitz https://github.com/kennethreitz
Maybe find a very well received project on GitHub and check out the author and see some of his code
I used to follow Edmond's detailed posts on Quora and that led me to buy his book. I am yet to complete but like it so far.
> Reduce Operational Complexity
If I hook everything into slack I have a simple interface that can cover and reflect all my needs!
If I hook everything into slack I have a simple interface that can cover and reflect all my needs!
I pwrsonally found that Refactoring often and unit testing don't play nicely together. A huge refactoring lead to a lot of rewriting of unit tests since they weren't compiling anymore. I was able to reuse test logic though.
Does this violate copyright? It appears to be a clear derivative work. I ask because this is something I'd love to see more of, but I'd be afraid of doing myself because I don't want to get a C&D.
Is a book review a derivative work? The author of the book is in here politely answering questions rather than crying "you copied!" so the nice summary of his ideas must feel ok to him...
I don't think the original notes do, but there is this comment by the owner of the gist:
"FWIW: I didn't produce the content present here.
I've just copy-pasted it from somewhere over the Internet, but I cannot remember exactly the original source. I was also not able to find the author's name, so I cannot give him/her the proper credit."
How convenient? It was copy/pasted from somewhere, but oops, can't remember where or who wrote it, oh well, I'll just put it under my name :)
"FWIW: I didn't produce the content present here.
I've just copy-pasted it from somewhere over the Internet, but I cannot remember exactly the original source. I was also not able to find the author's name, so I cannot give him/her the proper credit."
How convenient? It was copy/pasted from somewhere, but oops, can't remember where or who wrote it, oh well, I'll just put it under my name :)
[deleted]
Next big thing is finding out the non-algorithmic capabilities of the human mind, and how to best utilize human in the loop.
The website is broken (sign up link not working) with ublock on. This is really unacceptable for a landing page.
I just skimmed the article, but it seemed a lot like a rip off of "The Pragmatic Programmer" to me.
[deleted]
Wow yet another Github Markdown README about how to be good at X or a list of things of X
It's just someone's notes from reading a book.
What's so surprising about Markdown?
who knew that Github would be used for "10 ways to do x" type of articles
People who applied the lessons of 10 ways to read the future.
Not one mention of using a spellchecker, surely that's high leverage: quick and easy, increases the quality of your output.
surely commenting on the spelling of something you understand is not a high priority, high leverage, effective use of your time?
> 80% of the impact comes from 20% of the work.
This simply has no basis in reality nor research and it pains me to see it propagated.
The old VLSI design koan is: "The first 90% of the project takes 90% of the schedule. The last 10% of the project also takes 90% of the schedule. 90% of the engineering occurs in the last 10% of the project."
This simply has no basis in reality nor research and it pains me to see it propagated.
The old VLSI design koan is: "The first 90% of the project takes 90% of the schedule. The last 10% of the project also takes 90% of the schedule. 90% of the engineering occurs in the last 10% of the project."
http://www.crn.com/news/security/18821726/microsofts-ceo-80-...
"About 20 percent of the bugs causes 80 percent of all errors, and--this is stunning to me--1 percent of bugs caused half of all errors."
"About 20 percent of the bugs causes 80 percent of all errors, and--this is stunning to me--1 percent of bugs caused half of all errors."
I was going to say the same thing. The 80 20 thing should be reserved to the higher-ups and marketers deciding what to implement. At the development level, zero value is provided by any less than 100 percent of the work. Too many developers just focus on the 20 percent, leaving the project 4/5 unfinished.
Your assuming complete and correct requirements. 80 20 is great when you get fuzzy reqs and have to make a decision.
The exact proportion might differ and never is that, but the concept is conserved.
Yes it does. The 80/20 rule cleanly fits an exponential distribution. The assumption is then that the work to implement any given feature in a project follows an exponential , and this appears to hold reasonably true in practice.
All you did was move the question--why does this thing fit an exponential distribution?
The birth project of agile--the Chrysler Comprehensive Compensation project--should have been a wonderful example of the 80/20 rule. They implemented the most important chunks of the project and got about 80% of the cases correct--totally awesome.
Except--it wasn't. The value of the project was in handling all of the exceptional cases. And those cases started consuming VAST quantities of resource.
80/20 only works when you can interchangeably wipe out tasks without affecting the result. Most engineering is NOT like that.
Analyzing the soil may not take very long when building a bridge, but you can't skip it.
The birth project of agile--the Chrysler Comprehensive Compensation project--should have been a wonderful example of the 80/20 rule. They implemented the most important chunks of the project and got about 80% of the cases correct--totally awesome.
Except--it wasn't. The value of the project was in handling all of the exceptional cases. And those cases started consuming VAST quantities of resource.
80/20 only works when you can interchangeably wipe out tasks without affecting the result. Most engineering is NOT like that.
Analyzing the soil may not take very long when building a bridge, but you can't skip it.
As far as I can see, what you described perfectly fits the 80/20 rule.
I feel like this is spoken by someone who hasn't seen more than one technology cycle come and go.
What I've observed - having started my career back in the Java-will-eat-the-desktop days and then adapted through webapps, big data, mobile, and now AI - is that the people who are best positioned to capitalize on an emerging technology wave are the ones who started working on it before anyone realized it was important, just because it was interesting to them. They're the ones who write the papers and software that everyone else evangelizes, and then get multi-million-$ signing bonuses or stock grants (or billions of dollars worth of cryptocurrency) when corporate interests catch on that this is a new technology wave. But at the time they start working on the idea, it's both useless and unlikely to work.
You can make a decent living always being on the look out for a new technology wave and jumping on it as soon as it's clear that it's hot. I spent much of my 20s doing that, and made enough money doing so that I can take it a bit easier now. But it's exhausting, and you'll never be the one actually driving change.
It's also usually not clear what's the "wrong idea" except in retrospect. DropBox is rsync with cloud storage and some pretty slick desktop app integration, done at a time when everybody thought that desktop apps were dead and Drew's Windows hacking skills were old news. But it's that familiarity with old technology that put him in a place to realize that new technology could make the old technology dramatically more useful, to the tune of a $10B company.