The Engineer/Manager Pendulum

The Engineer/Manager Pendulum” is a great article about a career shift from engineering to management.  Anybody who’s in engineering now and plans or even just wants to become a manager should read this.  Anybody responsible for “promoting” engineers to managers must read this too.

Eight Rules for Effective Software Production

Timofey Nevolin wrote an excellent article “Eight Rules for Effective Software Production” over at Toptal.com.  The whole thing is well worth a read, but here are the 8 rules to get you started:

  1. Understand the IT Mentality
  2. Do Not Mix Software Production and Development Methodologies
  3. Use Persistent Storage as an Extension to Human Memory
  4. Stop Wasting Time on Formal Time Estimation
  5. Understand the Cost of Switching Tasks and Juggling Priorities
  6. Use Architecture Reviews as a Way to Improve System Design
  7. Value Team Players
  8. Focus on Teamwork Organization

All of these are good and true, but if I had to pick one, I’d say that rule 4 is my personal favorite.  Sometimes I feel like I’ve spent a good quarter of my life in meetings, discussions, and other estimation sessions.  And looking back at all of them, I have to honestly say that they all of them were a waste of time.  The only useful part of an estimation session is a high-level project plan, but that can be achieved with a project planning session – much narrower goal, much more measurable, and much easier to achieve.

Is group chat making you sweat?

Jason Fried has an excellent write-up on the pros and cons of using group chat for the team communications, and some of the ways to make it better. We use HipChat in the company and while it’s vital to our operations and I can’t even begin to think how we could do what we do without it, it does have some negative side effects – exactly as James describes them.

The most valuable advice out of that long article is this one (I’ve heard it before a few times, but it’s worth repeating):

Think about it like sleep. If someone was interrupted every 15 minutes while they were trying to sleep, you wouldn’t think they’d be getting a good night’s sleep. So how can getting interrupted all day long lead to a good day’s work?

 

A Million Words Published at Work in a Remote Company

Sara Rosso shares some thoughts on what to document and share, after publishing over a 1,000,000 words while working at Automattic.  Here’s the gist of it:

  • If you’re the go-to person for something in your company, consider how much of it is just gatekeeper information you could document properly to help someone else learn/grow from or work on independently.
  • Separate out processes and historical background from your strategic expertise. Processes and backstory are not really ‘what you know.’ It’s much better to be a person someone asks ‘why’ or ‘when’ to do something vs. the logistics of a ‘how.’ How can and should be documented for others to build off of regardless of your involvement. This should free you up to be more involved in the why, the new, and the next of your work.
  • If you’re repeating yourself in private chats or (gasp!) email on a specific topic, document it. That’s also what drove me to create this blog – being able to answer someone’s question with an answer you’ve already carefully crafted for someone else is a great feeling (and a great use of your time)!
  • Will someone want to know why you decided or executed something a specific way later? Share as much background as possible so colleagues are brought up to speed immediately. Share the setup & thought process you went through, where to find more information, and even the facts, ideas, or information you considered but deemed outside of scope for the particular project. My goal is to hopefully never have someone ask “where did this come from?” or “what’s your source?” or “did you consider this?” (when I had) and instead focus on enriching the discussion or challenging my ideas vs. asking me for information I should have provided in the original post.
  • Gather the best, most complete, or authoritative things you’ve authored and submit them as potential onboarding materials for new team members. Challenge them to ask questions and to find something you need to document.
  • If important progress is made, be sure to update your documentation, or retire in favor of something newer or more complete. We do this by linking from old posts to new ones, and all it takes is a quick comment and a link on an old post.

What are some things you wish you knew when you started programming?

Quora thread on “What are some things you wish you knew when you started programming?” is a goldmine of wisdom.  Irrelevant of how experienced you – whether you’ve been programming for decades or just thinking about a new career path, which programming languages and technology stacks you use, whether you’ve completed format education or taught yourself everything you know, I’m sure you’ll find valuable lessons and food for thought in there.

On Impostor Syndrome

David Walsh shares some thoughts on an impostor syndrome.  I’m sure anyone in the tech industry can relate.  I certainly do.

“Impostor” is a powerful word but that’s how I have felt during all of my career as a professional web developer. I feel like I’ve learned every day of the ride but I feel like I’m way behind. I feel like people see me as something of an expert where I see myself as an accident waiting to happen. I’m a complete impostor. A fraud.

Apart from the honesty of his feelings, I like his ways of snapping out of it.  They do work for me too:

  • Look at your (hopefully decent) employment history and know that, on a basic level, you’re much more wanted than you’re wanted gone
  • Log onto the IRC channel of a skill you feel comfortable with and answer questions of those asking
  • Realize that people who consider themselves “experts”, and don’t go through waves of self doubt, are idiots that are so arrogant to not know what they don’t know
  • Remember the last time a non-developer friend asked you the most basic of computer-related questions
  • Perform any simple exercise in the JavaScript console
  • BLOG!  The worst thing that can happen is someone corrects you and you learn something out of it
  • Review your code and find little nits to fix

One other thing that helps me, is this bit by Joe Rogan:

He talks more generically about life, but I think it’s equally applicable to technology knowledge as well.

Engineers Salary Data

Amitj Aggarwal, former Staff Engineer at Google (2008-2012), has collected a whole bunch of data in regards to engineers salaries, in USA and worldwide.  His points seem to be overly optimistic at times, but I don’t have any links handy to contradict his research.

Here are a few points to get you started:

  • Zoho, Salesforce pay 40% more than Oracle, Cisco, GE!!!
  • Top 7% or so engineers at Netflix, Amazon, Google, Facebook are paid more than $1.4M per year. Next 10% make $700K on average.
  • Facebook has lost relevance to Slack, LinkedIn, Snapchat, Pinterest and Quora. If you are working at Facebook ask for a 50% raise else move to a startup.
  • Oracle is loosing to cloud startups. If you are working at Oracle ask for a 60% raise else move to a startup.
  • ENGINEERS DO NOT WASTE MONEY ON AN MBA. You will make 2X more on average as an engineer.
  • Tableau, Splunk, Slack, Airbnb, Quora, Twitter, Facebook, Google pay more than $320K salary to their top hires. Definitely interview at these fine places. Uber top engineer salaries are $190-340K per year.
  • Starting salaries for fresh software engineering graduates is now $130K-160K. Ask shamelessly. For the best ones its ~$180K.
  • Apple pays 60% more than Samsung.