[deleted]
Effective Engineer – Notes
31–40 of 236 posts
Re: Effective Engineer – Notes
#32Hi! I'm Edmond, the author of the book. Happy to answer any questions about my two-year journey in self-publishing the 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?
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...
Re: Effective Engineer – Notes
#33This 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 " or "growth mi…
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…
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.
Re: Effective Engineer – Notes
#34Does 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.
Re: Effective Engineer – Notes
#35Earlier quoted context omitted.
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.
That's the deal though isn't it? They pay me real money - I do real work for them.
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).
Re: Effective Engineer – Notes
#36This 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 " or "growth mi…
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 Goog…
>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.
Re: Effective Engineer – Notes
#37On the "read code written by brilliant engineers" point, as someone just starting to learn Python, where would I find some?
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
Re: Effective Engineer – Notes
#38This 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 " or "growth mi…
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 exp…
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.
Re: Effective Engineer – Notes
#39On 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.
Re: Effective Engineer – Notes
#40On the "read code written by brilliant engineers" point, as someone just starting to learn Python, where would I find some?
Anything written by Kenneth Reitz https://github.com/kennethreitz