"Opportunity cost of working on wrong ideas can set back growth by years."
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.
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.
> 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
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 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.
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%.
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.
"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.
> 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"!
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.)
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.
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?
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.
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...
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?
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).
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.
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.
> 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.
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.
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.
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.
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.
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.
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.
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.
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?
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.
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.
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.
[+] [-] nostrademons|8 years ago|reply
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.
[+] [-] edmondlau|8 years ago|reply
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...
[+] [-] brucephillips|8 years ago|reply
[+] [-] ringaroundthetx|8 years ago|reply
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
[+] [-] IronKettle|8 years ago|reply
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.
[+] [-] edmondlau|8 years ago|reply
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/...
[+] [-] jakevoytko|8 years ago|reply
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%.
[+] [-] pm90|8 years ago|reply
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.
[+] [-] barrkel|8 years ago|reply
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.
[+] [-] dualogy|8 years ago|reply
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"!
[+] [-] lazyasciiart|8 years ago|reply
[+] [-] dejawu|8 years ago|reply
(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.)
[+] [-] Waterluvian|8 years ago|reply
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.
[+] [-] goialoq|8 years ago|reply
[+] [-] guelo|8 years ago|reply
[+] [-] simonbc123|8 years ago|reply
Once the majority is mediocre, it becomes accepted practice.
[+] [-] henrik_w|8 years ago|reply
- 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...
[+] [-] edmondlau|8 years ago|reply
[+] [-] edmondlau|8 years ago|reply
[+] [-] 0xdeadbeefbabe|8 years ago|reply
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?
[+] [-] mzzter|8 years ago|reply
[+] [-] ashwinaj|8 years ago|reply
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...
[+] [-] brucephillips|8 years ago|reply
[+] [-] gdubs|8 years ago|reply
[+] [-] jyriand|8 years ago|reply
[+] [-] makecheck|8 years ago|reply
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.
[+] [-] beager|8 years ago|reply
[+] [-] anichale|8 years ago|reply
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.
[+] [-] xstartup|8 years ago|reply
[+] [-] Terr_|8 years ago|reply
[+] [-] inetknght|8 years ago|reply
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.
[+] [-] whistlerbrk|8 years ago|reply
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.
[+] [-] crispyambulance|8 years ago|reply
Idealism, IMHO, acts as a motivator and helps folks get through the obstacles that inevitably block progress.
[+] [-] romanovcode|8 years ago|reply
[deleted]
[+] [-] partycoder|8 years ago|reply
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.
[+] [-] nicodjimenez|8 years ago|reply
[+] [-] andendau|8 years ago|reply
[+] [-] rondysousa|8 years ago|reply
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.
[+] [-] Blazespinnaker|8 years ago|reply
[+] [-] KKKKkkkk1|8 years ago|reply
[+] [-] foopod|8 years ago|reply
+ The most valuable thing? + The riskiest thing? + The simple thing?
[+] [-] edmondlau|8 years ago|reply
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.
[+] [-] jrs235|8 years ago|reply
Edit: [guesstimated]
[+] [-] jodrellblank|8 years ago|reply
Does any of this seem a bit Shepard Tones to anyone else?
https://www.youtube.com/watch?v=OsBanpBQj0k
(ever-ascending-tones audio illusion)
[+] [-] swanson|8 years ago|reply
Thinking more strategically about the most effective way to spend my own time and energy was easily worth the nominal cost of the book.
[+] [-] yks|8 years ago|reply
[+] [-] bra-ket|8 years ago|reply
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.
[+] [-] yanilkr|8 years ago|reply
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”.
[+] [-] apthnz|8 years ago|reply
[+] [-] bharatmeda|8 years ago|reply