7 ms·

Staff+ engineers, how do you learn new technologies at a new company?

42 points by vincentchau 4y ago

Let's say that you're a Ruby on Rails veteran and now you get a job at Google, where you need to learn Go. What's your approach to quickly learn new framework/programming languages?

icsa 4y ago
Let people know that you don't respond to personal communications nor interruptions during working hours on weekdays. Keep work meetings to 3 hours per day or less and only during working hours. Give yourself at least two 1 hour blocks per day for deep work. You'll have plenty of time to learn new technologies.
- icedchai 4y ago
  Based on personal experience, 3 hours per day of meetings is hell. Once you factor in all the time lost to context switching this consumes half your day. This coming year I really have to work on cutting back on zooms for my own mental health.
- kccqzy 4y ago
  Are you sure staff+ engineers can keep meetings to 3 hours per day? Every single staff+ engineer I know has more meeting than that. 3 hours per day is around the meeting load of senior engineers, not staff.
  - sibeliuss 4y ago
    Really depends on the company, full stop.
    - icsa 4y ago
      Find a company culture that does have meeting-itis.
  - kami8845 4y ago
    At my current job (sr. eng) I have an average of 45 minutes of meetings per day
  - icedchai 4y ago
    Many (most?) organizations seem to have too many meetings. 3 hours daily is insane. It’s amazing what we tolerate for a paycheck.
belfalas 4y ago
Your question is not quite the right framing. By the time you hit "Staff level" you should have learned that programming language and framework are simply window dressing on top of the fundamentals. The fundamentals are things like files, sockets, TCP/IP, operating systems. Or said differently: things that have been with us since the 20th century. Wisdom I got many years ago from an old hand was to run this thought experiment: * An HTTP request * A business object * A database transaction That's web architecture, more or less. Someone requests something and your programs mission is to find that something as fast as possible. In some cases Rails is a great fit, depending on the constraints. Under different constraints Go is the right solution. When learning the new technologies the key is understanding what problem that technology is trying to solve most optimally. Additionally, what really separates a "Senior Software Engineer" from the levels above is understanding that after a certain point, technology is irrelevant. Social factors drive decisions much more than technical considerations (Conway's Law).
- nivertech 4y ago
  >The fundamentals are things like files, sockets, TCP/IP, operating systems. Or said differently: things that have been with us since the 20th century. Wisdom I got many years ago from an old hand was to run this thought experiment: * An HTTP request * A business object * A database transaction That's web architecture, more or less. I disagree, IMO the fundamentals are: Naming Things, Immutability, Idempotence, Behavior/Workflows/Transactions/Business Processes, Distributed Systems, Cryptography, Algorithms and Data structures, etc. In addition to technical fundamentals, there are people fundamentals/soft-skills.
  - belfalas 4y ago
    > Naming Things, Immutability, Idempotence, Behavior/Workflows/Transactions/Business Processes, Distributed Systems, Cryptography, Algorithms and Data structures, etc. All of these things are footnotes and implementation details to what I wrote.
    - nivertech 4y ago
birdymcbird 4y ago
At staff/principal level, my experience has been less about learning a new technology and more about organizational and customer needs. - Experiment and learn - Drive tech alignment across teams and orgs - Focus on the key decisions - Kill stupid things early on. If you fail at this, you essentially fail at the job - Be the eyes and ears to look around corners… we’re shipping some product X. We have product teams, TPMs, software managers basically a small army of friction: competing priorities, territorialism and empire building, and then the doers who you really need to help make this product happen. Are the right people working in the right problems? Are we solving them in an efficient way, using the right tooling or tech? - Partner up with the other passionate people in management. Define the tech vision and architecture so devs can continue building without burning out or running into stupid obstacles that demotivate them - Help define the culture. Mentor. Figure out what people are good at and advise the managers on who is best suited to a problem: function of their skills, growth areas, need of business, etc - have strong opinions. Don’t sway with the wind. To summarize: your focus is resounding impact. Sweat the details but only the important ones. If you need to learn a language or how something works, do your own research and go consult with other smart people in the space. Don’t pretend to know things you don’t. Be up front and ask a junior person to help you make sense of what it is you have, why are things the way they are, and how we got here.
- thrwya123 4y ago
  Really great answer! Thanks for it. As a freshly promoted staff engineer I am also interested in some more details, because it is not easy to find some good resources on this topic. > Kill stupid things early on Can you give some examples of stupid things? > have strong opinions This is one of the things I hear a lot, but again, what are those, any examples? My opinion could be wrong and I can't keep it strongly, especially when surrounded with smart people.
  - AnimalMuppet 4y ago
    Stupid ideas often take the form of "let's spend six months of the team's time on this thing that only 3 people in world will care about". The way you kill such things is 1) by telling the truth about how much it's going to cost to do, and 2) by asking for evidence that the idea will pay back the effort required. (I mean, to some degree all development is done on faith that there will be a market there. But an idea that will take 6 months for the team needs a more solid basis than an idea that will take an afternoon for an individual.)
nivertech 4y ago
Your example is too simple, GoLang is easy to learn and use, that was one of its design objectives. A professional SW Engineer can be proficient in the language in couple of days. But from your question I get that you need to be able to get a rough estimate how much time it will take to learn the specific technology. And if it's too long, maybe abandon the idea altogether. It's especially relevant if you're doing it part time or after your main job.
mattm 4y ago
I'm not a Staff+ level engineer but what's always worked for me at a new company is getting a book or two on the target language and reading those everyday for about 30-60 minutes until I feel up to speed enough. It's allowed me to ramp up quickly.
dev_0 4y ago
[dead]
bad_username 4y ago
Solution architect here. Having to grok some new tech quickly and put it to use ASAP is almost a weekly occurrence. The most important thing (to me) when learning a new technology is learning what it _can do_ in the most complete way possible. Reason: when I invest into learning a technology, afterwards I want to be able to quickly pick the feature that is most suitable for a particular need without the risk to reinvent some kind of wheel in a dumb and costly way. And for that I must have a mental map of all the features, at least superficially. Everything else you an look up. (The same principle goes for the total of all the technologies I have learnt before). In practice I make sure I scan _all_ the documentation for the product and build a cheat sheet of the features, concepts, configuration flags, best practices etc. I will consult the sheet later, but the process of building it helps immensely to construct the map of _what's possible_ with this thing. A recent example - I had to design a GCP solution while not having much experience in GCP. I sat down and browsed the introductory docs of all the hundred plus (?) products that GCP offers, and built a cheat sheet categorizing the features and intents of each and every one. This took me around two days, and ultimately of in the solution I only used a handful services out of the hundred. But these were exactly the ones that solved the problem, including a couple of exotic ones that I wouldn't have guessed even existed. For the cheat sheets I use Obsidian which is excellent for this.
- Dowwie 4y ago
  Would you consider sharing your GCP Obsidian vault? Very curious about your workflow..
navyad 4y ago
-- Read official docs -- Use Repl to try examples in the doc -- build side project
pjmlp 4y ago
I usually tend to get to learn languages based on projects, applying to companies without previous experience on their stack hardly works out, unless coming as reference from someone else. On which case I expect being offered enough time and training opportunities. Otherwise the languages I know are more than enough, what you need are soft skills, domain knowledge and architecture design. Getting yet another way to write the same algorithms is kind of focusing on the tree instead of the forest.
drakonka 4y ago
I just dive in and learn as I go by looking at the rest of the code-base and familiarizing myself with their chosen patterns, language documentation, and trial + error. Core principles remain mostly the same regardless of language, and anything that's not the same is pretty quick to pick up with background knowledge of peripheral technologies and Google.

42 points by vincentchau 4y ago

Let's say that you're a Ruby on Rails veteran and now you get a job at Google, where you need to learn Go. What's your approach to quickly learn new framework/programming languages?

icsa 4y ago

Let people know that you don't respond to personal communications nor interruptions during working hours on weekdays. Keep work meetings to 3 hours per day or less and only during working hours. Give yourself at least two 1 hour blocks per day for deep work. You'll have plenty of time to learn new technologies.

icedchai 4y ago
Based on personal experience, 3 hours per day of meetings is hell. Once you factor in all the time lost to context switching this consumes half your day. This coming year I really have to work on cutting back on zooms for my own mental health.
kccqzy 4y ago
Are you sure staff+ engineers can keep meetings to 3 hours per day? Every single staff+ engineer I know has more meeting than that. 3 hours per day is around the meeting load of senior engineers, not staff.
- sibeliuss 4y ago
  Really depends on the company, full stop.
  - icsa 4y ago
    Find a company culture that does have meeting-itis.
- kami8845 4y ago
  At my current job (sr. eng) I have an average of 45 minutes of meetings per day
- icedchai 4y ago
  Many (most?) organizations seem to have too many meetings. 3 hours daily is insane. It’s amazing what we tolerate for a paycheck.

belfalas 4y ago

Your question is not quite the right framing. By the time you hit "Staff level" you should have learned that programming language and framework are simply window dressing on top of the fundamentals. The fundamentals are things like files, sockets, TCP/IP, operating systems. Or said differently: things that have been with us since the 20th century. Wisdom I got many years ago from an old hand was to run this thought experiment: * An HTTP request * A business object * A database transaction That's web architecture, more or less. Someone requests something and your programs mission is to find that something as fast as possible. In some cases Rails is a great fit, depending on the constraints. Under different constraints Go is the right solution. When learning the new technologies the key is understanding what problem that technology is trying to solve most optimally. Additionally, what really separates a "Senior Software Engineer" from the levels above is understanding that after a certain point, technology is irrelevant. Social factors drive decisions much more than technical considerations (Conway's Law).

nivertech 4y ago
>The fundamentals are things like files, sockets, TCP/IP, operating systems. Or said differently: things that have been with us since the 20th century. Wisdom I got many years ago from an old hand was to run this thought experiment: * An HTTP request * A business object * A database transaction That's web architecture, more or less. I disagree, IMO the fundamentals are: Naming Things, Immutability, Idempotence, Behavior/Workflows/Transactions/Business Processes, Distributed Systems, Cryptography, Algorithms and Data structures, etc. In addition to technical fundamentals, there are people fundamentals/soft-skills.
- belfalas 4y ago
  > Naming Things, Immutability, Idempotence, Behavior/Workflows/Transactions/Business Processes, Distributed Systems, Cryptography, Algorithms and Data structures, etc. All of these things are footnotes and implementation details to what I wrote.
  - nivertech 4y ago

birdymcbird 4y ago

At staff/principal level, my experience has been less about learning a new technology and more about organizational and customer needs. - Experiment and learn - Drive tech alignment across teams and orgs - Focus on the key decisions - Kill stupid things early on. If you fail at this, you essentially fail at the job - Be the eyes and ears to look around corners… we’re shipping some product X. We have product teams, TPMs, software managers basically a small army of friction: competing priorities, territorialism and empire building, and then the doers who you really need to help make this product happen. Are the right people working in the right problems? Are we solving them in an efficient way, using the right tooling or tech? - Partner up with the other passionate people in management. Define the tech vision and architecture so devs can continue building without burning out or running into stupid obstacles that demotivate them - Help define the culture. Mentor. Figure out what people are good at and advise the managers on who is best suited to a problem: function of their skills, growth areas, need of business, etc - have strong opinions. Don’t sway with the wind. To summarize: your focus is resounding impact. Sweat the details but only the important ones. If you need to learn a language or how something works, do your own research and go consult with other smart people in the space. Don’t pretend to know things you don’t. Be up front and ask a junior person to help you make sense of what it is you have, why are things the way they are, and how we got here.

thrwya123 4y ago
Really great answer! Thanks for it. As a freshly promoted staff engineer I am also interested in some more details, because it is not easy to find some good resources on this topic. > Kill stupid things early on Can you give some examples of stupid things? > have strong opinions This is one of the things I hear a lot, but again, what are those, any examples? My opinion could be wrong and I can't keep it strongly, especially when surrounded with smart people.
- AnimalMuppet 4y ago
  Stupid ideas often take the form of "let's spend six months of the team's time on this thing that only 3 people in world will care about". The way you kill such things is 1) by telling the truth about how much it's going to cost to do, and 2) by asking for evidence that the idea will pay back the effort required. (I mean, to some degree all development is done on faith that there will be a market there. But an idea that will take 6 months for the team needs a more solid basis than an idea that will take an afternoon for an individual.)

nivertech 4y ago

Your example is too simple, GoLang is easy to learn and use, that was one of its design objectives. A professional SW Engineer can be proficient in the language in couple of days. But from your question I get that you need to be able to get a rough estimate how much time it will take to learn the specific technology. And if it's too long, maybe abandon the idea altogether. It's especially relevant if you're doing it part time or after your main job.

mattm 4y ago

I'm not a Staff+ level engineer but what's always worked for me at a new company is getting a book or two on the target language and reading those everyday for about 30-60 minutes until I feel up to speed enough. It's allowed me to ramp up quickly.

dev_0 4y ago

[dead]

bad_username 4y ago

Solution architect here. Having to grok some new tech quickly and put it to use ASAP is almost a weekly occurrence. The most important thing (to me) when learning a new technology is learning what it _can do_ in the most complete way possible. Reason: when I invest into learning a technology, afterwards I want to be able to quickly pick the feature that is most suitable for a particular need without the risk to reinvent some kind of wheel in a dumb and costly way. And for that I must have a mental map of all the features, at least superficially. Everything else you an look up. (The same principle goes for the total of all the technologies I have learnt before). In practice I make sure I scan _all_ the documentation for the product and build a cheat sheet of the features, concepts, configuration flags, best practices etc. I will consult the sheet later, but the process of building it helps immensely to construct the map of _what's possible_ with this thing. A recent example - I had to design a GCP solution while not having much experience in GCP. I sat down and browsed the introductory docs of all the hundred plus (?) products that GCP offers, and built a cheat sheet categorizing the features and intents of each and every one. This took me around two days, and ultimately of in the solution I only used a handful services out of the hundred. But these were exactly the ones that solved the problem, including a couple of exotic ones that I wouldn't have guessed even existed. For the cheat sheets I use Obsidian which is excellent for this.

Dowwie 4y ago
Would you consider sharing your GCP Obsidian vault? Very curious about your workflow..

navyad 4y ago

-- Read official docs -- Use Repl to try examples in the doc -- build side project

pjmlp 4y ago

I usually tend to get to learn languages based on projects, applying to companies without previous experience on their stack hardly works out, unless coming as reference from someone else. On which case I expect being offered enough time and training opportunities. Otherwise the languages I know are more than enough, what you need are soft skills, domain knowledge and architecture design. Getting yet another way to write the same algorithms is kind of focusing on the tree instead of the forest.

drakonka 4y ago

I just dive in and learn as I go by looking at the rest of the code-base and familiarizing myself with their chosen patterns, language documentation, and trial + error. Core principles remain mostly the same regardless of language, and anything that's not the same is pretty quick to pick up with background knowledge of peripheral technologies and Google.