// wisdom

Wisdom

A moodboard of tweets and links I keep coming back to.

No CS Degree

Inspiring interviews with successful self-taught and bootcamp developers

Simplicity

It's great to work with people who can see sophistication in simplicity.

Jaana Dogan ヤナドガン @rakyll

Distinguished Engineers are not always right & importance of the feedback

When I first joined Google, I was reading a design doc out of curiosity. I saw a comment from a distinguished engineer contradictory to my experience. I immediately thought I must have been wrong all these years because there's no way I know better than a distinguished engineer.

Jaana Dogan ヤナドガン @rakyll

A coworker asked why I don't reply and explain my perspective. He also kept continuing it should never matter who I'm responding to. "Distinguished engineers know less than you think." I responded. They incorporated that feedback and made changes.

Jaana Dogan ヤナドガン @rakyll

That week changed my life. I rarely suffer from imposter's syndrome knowing that we are good at different pieces of the puzzle, and what matters is to be able to combine our knowledge and experience to build great things.

Jaana Dogan ヤナドガン @rakyll

Chasing FAANG

I was briefly on Blind today (don't ask why) and there are threads on how chasing a FAANG job can bring you more happiness rather than working there because you'll produce more adrenaline during the chase. Is this real life?

Jaana Dogan ヤナドガン @rakyll

Staff Engineering

"Does the title even matter?" at http://StaffEng.com was a good read. IMO, the title changes the nature of taking risks. It's expected for staff+ to initiate new projects and fail more often. Until you get there, you risk your credibility more often and more significantly.

Jaana Dogan ヤナドガン @rakyll

Getting to staff requires dealing with high levels of ambiguity while taking risks and fighting the good fights and delivering results when few people are believing you. It's constant anxiety and overhead if the title is not helping you to communicate your track record.

Jaana Dogan ヤナドガン @rakyll

Junior Devs

A junior dev on my team told me the first feedback she got at work was that she was asking too many questions. WHAT!? Let people ask ALL the questions they need! It's maybe a bit annoying for you in the moment, but your time ain't worth more than their confidence and career!

Monica Dinculescu @notwaldorf

I don't know who needs to hear this, but your goal as a senior dev/manager/mentor/basically anyone who's been on the team longer than a more junior dev is to HELP THE OTHER PERSON SUCCEED. And that means answering all their questions, so that they can understand more!

Monica Dinculescu @notwaldorf

I'm so angry about this zero sum attitude. If you're worried that helping the other person takes something away from you, or they'll take your place or something, then maybe you ain't the hot shot dev you thought you were, pal. And maybe you should've learnt more as a junior?? 🙃

Monica Dinculescu @notwaldorf

Job Title

Titles matter. 10 years ago, when I was junior, I didn’t go for promo for a while. I accumulated more leadership over time. My perf said I’m splitting myself too thin even though I was just performing at the next level. I got promoted and my next perf appreciated my “thin” split.

Jaana Dogan ヤナドガン @rakyll

I'd be happier in a world titles mattered less but titles change the way others perceive the content and scope of your work. Titles also set the expectations for many people because not everyone can work at the same level on a project.

Jaana Dogan ヤナドガン @rakyll

Inclusivity problems in tech has a lot to do with titles. You won't be invited to a cross-team strategy meeting if you are officially a junior person regardless of how you perform. It's your leader's job to start including you. If they fail, you're missing opportunities.

Jaana Dogan ヤナドガン @rakyll

Titles matter because it impacts the way people outside of your immediate team/org work with you. If I wanted to work on projects only directly impacting a few engineers, I'd not care about titles. If you need to go beyond, keeping levels representative of your scope matters.

Jaana Dogan ヤナドガン @rakyll

Once you step outside the boundaries of your company, describing the scope and responsibilities of your title starts to matter. It's not unlikely for a principle engineer at a XXX billion dollar company to operate with a larger scope than many SV CTOs.

Jaana Dogan ヤナドガン @rakyll

Opinions

It's almost impossible to grow in career if you cannot express your personal opinions even though they are unpopular.

Jaana Dogan ヤナドガン @rakyll

@rakyll A friend used to say that if you are not getting in trouble at least once every 6 months, you are not pushing it. So maybe the way you grow in a career is exactly by expressing those unpopular opinions. But how this is perceived will vary from org to org

mamadero @mamadero

@mamadero Once a manager said this exact thing and it really changed my life.

Jaana Dogan ヤナドガン @rakyll

Big Companies

All the anecdotal stories about how large companies work are cringe-worthy. After working years for such companies, you can't truly understand how things ended up being the way they are because solutions are organically growing.

Jaana Dogan ヤナドガン @rakyll

At large companies, solution X probably has 20+ other alternatives but you never hear about them externally because only X has been externalized. What's external has a tendency to be "cutting-edge" because externalizing solutions means PR and attracts others.

Jaana Dogan ヤナドガン @rakyll

Developing New Language

Productionization new languages at Google is a lot of work. As a person who witnessed two attempts, this thread is what I learned. Google has an incubation policy for new languages. You start by being experimental, then become incubator and then graduate to a canonical language.

Jaana Dogan ヤナドガン @rakyll

Being able to explain why you are introducing a new language and how you are going to do cost analysis is VERY CRITICAL at the proposal stage. You can't get around by underestimating this step.

Jaana Dogan ヤナドガン @rakyll

Our SRE team has a lot of requirements from our languages. They enjoy identical contact surfaces with other languages, functional parity in terms of tools. But most importantly, SREs want to be able to understand and change the code base they support.

Jaana Dogan ヤナドガン @rakyll

Focus on the operability aspects of the language runtime, and making the monitoring and debugging surface and tooling very similar to other languages. Extra credits if you can improve incident response with your new language.

Jaana Dogan ヤナドガン @rakyll

It's a must to meet the operating system and architecture requirements from the runtimes and Google hardware-specific stuff's. Follow Borg's production-ready language requirements. You need all the essential debugging z-pages: /varz, /statz, /heapz, /profilez, ...

Jaana Dogan ヤナドガン @rakyll

Readability is a must. You need a style guideline and a proper readability process. You need to figure out the early readability approvers. Then, where to put things in the monorepo? How to handle third-party packages, modules, etc? How do you vendor?

Jaana Dogan ヤナドガン @rakyll

Then, it's an endless list of integrations with the developer tools we build in house. Build system support, developer tooling support, indexer support, testing and CI support, ... This list is endless and there is no easy way around.

Jaana Dogan ヤナドガン @rakyll

Critical libraries! At Google, everything is in-house built and you need to provide client libraries for all the critical services. You also need a proto compiler. You can't push new services without gRPC support. If gRPC doesn't already have support for your language, good luck!

Jaana Dogan ヤナドガン @rakyll

Essential runtime metrics should be exported and should have similar parity with other languages. You have to also have a plan for runtime version requirements, update policy and security patches policy. For example, we start using Go in production as soon as there is an RC.

Jaana Dogan ヤナドガン @rakyll

Then we have other runtime policies and best practices. For example, graceful shutdown policies... A more granular example would be flushing logs on program exit. You have to document and provide convenience to these every day tasks.

Jaana Dogan ヤナドガン @rakyll

engEDU and internal training comes next. You have to represent the language support internally all across the tech stack. You need high quality reference code for critical services and internal training programs to teach the internal flavors. You will need internal case studies.

Jaana Dogan ヤナドガン @rakyll

Testimonials and success stories from other teams help the internal adoption! Especially large scale systems feel more confident once more examples of the new language exists in similar scales in production. It gives an idea about how mature the support and integrations are.

Jaana Dogan ヤナドガン @rakyll

Working on languages at Google is hard work but it is a good opportunity to learn the entire stack end-to-end. It allows you to inherit a lot of knowledge and work with a large number of production users closely.

Jaana Dogan ヤナドガン @rakyll

CS Degree

There is a major difference between saying "Not all software development jobs need a CS degree." and "No one should have CS degrees." I'm not sure people understand this obvious difference.

Jaana Dogan ヤナドガン @rakyll

Some people's arguments around developers without CS degrees are clustered around "the fact" they don't know maths or have enough analytical skills -- even though there is an overwhelming number of people pivoting from maths & other engineering fields to software development.

Jaana Dogan ヤナドガン @rakyll

I am not trying to say you can only learn maths or be analytical if you are coming from these fields. What I'm trying to say is that the reality is just so inconsistent with the counter arguments that it's hard to take them seriously.

Jaana Dogan ヤナドガン @rakyll

A lot of people are also missing the fact that a CS degree is giving you the 5-10% of what's needed to perform as a software developer unless you are specialized in some topics like robotics. Then you learn by reviews, mentorship and experience.

Jaana Dogan ヤナドガン @rakyll

Unpopular opinion: I see CS degrees complementary to our craft. It teaches a little bit of the foundations. It doesn't determine the boundaries of your knowledge or your technical depth. I benefited a lot from having one and would recommend it if you have time/money.

Jaana Dogan ヤナドガン @rakyll

Knowing what's in the CS curriculum and how inconsistent the quality of the education is also the reason why I'm criticizing people bullshitting about these programs. Understanding each individual's knowledge and skills is more valuable than checking boxes bc they have a degree.

Jaana Dogan ヤナドガン @rakyll

Conferences

Being able to attend to conferences is the peak privilege in tech. That's why they are not that relevant to practitioners in the big picture. Parts of our industry live in their bubbles to be able to acknowledge this fact and we have a long way to go.

Jaana Dogan ヤナドガン @rakyll

Working in a conference-driven economy made me see it first hand how painful this is to people who don't have access to these venues. They feel othered and excluded from critical collaboration opportunities and discussions (even if that's never been the intention).

Jaana Dogan ヤナドガン @rakyll

Good API

"A good API is not just easy to use but also hard to misuse." - JBD

Programming Wisdom @CodeWisdom

CAP

Too many people asked me about the CAP theorem in the last 10 years and I want to share my opinion on this for once: Not everyone understands that the definition of availability has a lot of nuances and the CAP theorem is talking about a specific measure of "availability".

Jaana Dogan ヤナドガン @rakyll

1: Availability of the node vs system Network partition tolerance is a way to achieve "high availability" in a system. So, people are confused how the availability and partition tolerance are orthogonal concerns.

Jaana Dogan ヤナドガン @rakyll

2: Availability vs health In the modern context, when we talk about availability, we mean "meeting SLOs" which includes latency objectives. The CAP theorem's availability doesn't capture latency and the CAP theorem has nothing to say about latency. Another source of confusion.

Jaana Dogan ヤナドガン @rakyll

If you are using the CAP theorem, it's sometimes a philosophical conversation to determine whether a system is CA or CP. It's due to the confusion about what A and P means and how orthogonal they are in the original model.

Jaana Dogan ヤナドガン @rakyll

This is unfortunately a large topic and my thoughts won't fit here... Even though it's limited in terms of compromises presented, I still think that the CAP theorem can be useful to teach how to think. It's just important to understand its shortcomings and people's confusions.

Jaana Dogan ヤナドガン @rakyll

Database Migrations

We're asked about database migration strategies often. Christoph Bussler's recent article overviews the whole spectrum. https://medium.com/@chbussler/zero-downtime-database-migration-and-replication-to-and-from-cloud-spanner-99ad0c654d12 - Migration and replication systems - Export/import - Incremental batch reading - Evaluation tooling - Dual-write

Jaana Dogan ヤナドガン @rakyll

System Design Interviews

System design interviews evolved quite a bit with cloud. Storage layer, regional/zonal availability, capacity planning, autoscaling, event-driven components and observability conversations were different in a pre-cloud era.

Jaana Dogan ヤナドガン @rakyll

Design Docs, RFCs, Etc

Another great article from @cramforce about design docs. If you are not discussing trade-offs or trying to address ambiguity, you may not need a design doc. https://www.industrialempathy.com/posts/design-docs-at-google/

Jaana Dogan ヤナドガン @rakyll

My ideas either fit into a tweet or a five-page design doc. I never saw them fitting into a one-pager. Why?

Jaana Dogan ヤナドガン @rakyll

Communication

The best software consulting advice I ever got was to avoid speaking in absolutes. "never" -> rarely "useless" -> I don't see the value in this use case "always" -> usually "none" -> few It helps keep technical conversations open.

Khalil Stemmler @khalilstemmler

Good Infrastructure

We (infrastructure folks) get credit by the lack of noise about our products/projects. Good infra just works and you can't tell it is there unless there is an outage.

Jaana Dogan ヤナドガン @rakyll

Bad Product Management

One problem in tech is high-level managers who doesn't have a clue about technical complexities but are trying to measure the impact of infrastructure projects and failing to understand their value proposition. There I said it.

Jaana Dogan ヤナドガン @rakyll

If I was an executive and if our main business was a developer product, I would be using our product on a daily basis as if I'm a practitioner. I wonder how many executives do this at any of the tech companies.

Jaana Dogan ヤナドガン @rakyll

Burnout

I'm never taking 6 months without a real vacation again, cause that shit does a number to your mental and emotional health. 😭

Iheanyi Ekechukwu @kwuchu

Burnout threads often imply its working too much. Whenever I’ve felt burnt out it was a misalignment with how I was spending my energy, not just the amount. Working too much makes me tired, but burnout feels like suspended momentum without a worthwhile goal.