Software Engineering Unlocked

Links:

• Honeycomb
• Charity's website
• Christine Yen: Co-founder of honeycomb
• Post on engineering management: the pendulum or the ladder
• Paper about Scuba - Facebook's Scuba data management system for real-time analysis

Show notes:

We start of by Charity explaining why she founded honeycomb. It all happened during her time at Facebook. She actually thought she will - after leaving Facebook - go on to be an engineering manager. But when she thought about how to engineer systems without all the tools and systems they had at Facebook, she realized that there is a big gap in the market. 

At Facebook, she relied heavily on a tool called Scuba. Scuba is Facebook's data management system to analyze and understand real-time data. Well, turns-out, outside of Facebook such great tools aren't available, or are not affordable. And because investors literally knocked at her door to fund her - after leaving Facebook - Charity took this chance and started honeycomb. 

In the early beginnings they literally just had four slides, an understanding of a problem (debugging and troubleshooting highly complex systems), and the desire to make an impact.

Over the next year, Charity and her co-founder Christine Yen went all heads-down and figure out what exactly they want to build and how to talk about it.

It was a long and painful process, but at one point they decided that the term observability is what describes best what they have in mind. (6:30)

Charity explains that through observing the output of a system an engineer can actually infer what is going on internally. So, finally they knew themselves what they want to build and how to talk about it: they tried to build a system they let's you understand any state the system has gotten itself into, even  if you have never seen this state before. 

And such systems can have a big impact on people's life - especially for Site Reliability Engineers, DevOps, and Developers. Charity and I talk about how to make on-call experiences better, and how developers are nowadays more and more needed in the operations phase of a system. (7:40)

Because even though we have Q&A departments, manual testers, dedicated operations peoples, Charity explains that also the engineers have to spend their time operating the systems. She says that nowadays there is no way to build reliable and maintainable systems, if the developers do not spend time actually understanding and analyzing how the system behaves in production.  

She also explains why staging areas are a bad idea, and how those falsified environments just contribute to us learning the wrong signals, and destroying our ability to make good judgments about the behavior of the system when actual in production. (15:00)

Charity also tells me that she thinks almost every developer should try out management at least for some time. She says that this experience gives engineers a new perspective and many valuable skills that  make them better engineers, even when they go back to engineering. (25:07)

Later Charity fills me in on their tech stack, and also explains why code reviews and communication are valued so highly at their company. (29:35)

Charity is a big believer of transparency and openness when it comes to sharing incident reports (33:37). Sharing revenue numbers on the other hand isn't something that's common in her market, and so, it would be a competitive disadvantage, she says (35:19).

In the last bit of the interview, Charity shares with me how she found her first investors, and how they feel much more stable, secure and on the right track with this second round of funding. Well, I really enjoyed talking to and learning from Charity and really admire her openness. Thank you Charity for being on my show. 

Links:

• Derrick's Twitter account
• Website of the Git project
• Website of GitGitGadget
• Linus appoints Junio Hamano as the Git maintainer
• Brian Harry's post about the largest Git repository

Show notes:

First, we talk about how it comes that Derrick, as a former professor, is now working for Microsoft as a principal software engineer. (0:10)

Derrick explains to me that even though he wasn't a "sophisticated" programmer when he applied for the Microsoft role, he has decent experience building tools to solve his own problems. (2:40)

During the interview process, Derrick stayed humble, curious and open-minded, he explained. (4:19)

When I wondered how his work as a former professor for theoretical mathematicians shaped his mindset as an engineer, he explains how he breaks down problems, similar to solving a mathematical theorem. (5:55)

Even though Derrick was a professor when he applied, he went through quite a typical interview process (for that time), including live coding, whiteboarding, and some "higher-order" questions, such as what has your biggest success been? (7:33)

I ask what was the first project Derrick was asked to contribute to when joining Microsoft. And he explains that his team was/is responsible to help the Windows team be able to use Git. And for that, Git must be made faster. (10:29)

Well, if he makes Git faster to work with Windows, I wonder if there are other projects out there that are large enough to also benefit from, for example, the Virtual File System for Git. Or is this improvement really specific to Windows? (13:37)

Derrick explains to me how his work for Microsoft and his contributions to the open-source system Git interconnect and also how they differ. (16:27)

Derrick seems to be in a very interesting position. Because, he works for Microsoft, but not solely on projects that Microsoft owns. In contrast, he works on Git. An independent open-source system, Microsoft has no authority over. This means that Derrick always has to look out for win-win-win situations for every enhancement or change he wants to introduce to Git. Also, he has to show why a change to Git is beneficial for both, for Microsoft and for the open-source community. (19:13)

Well, Derricks's Twitter profile says that he makes Git faster, and after talking to him, I now understand that he actually works on algorithmic changes to the underlying Git system to make that happen. So, I ask him what other changes he introduces when he sets out to speed up Git. (21:28)

Another thing that I want to know is whether such a mature and widely-used system can even be still improved. Derrick assures me that there is still plenty to work on. (23:49)

But, he also explains that changing such a system must be taken one step at a time. Maybe things are interconnected, and many side-effects must be considered. They are working collectively on a new version that will increase the performance substantially. But, as this changes fundamentally how Git works, things need time to cook. (25:44)

Because all the problems Derrick explains to me sound so exciting, I wonder how outsiders, like you and me, could contribute to this open-source system. (26:49)

Derrick explains that quite a few people contribute to Git, and fills me in who is contributing to this open-source project. (28:40)

Now, we start talking about software development processes. Derrick already mentioned code reviews before, but now he explains how code is reviewed through the mailing list. (29:50)

After that, Derrick explains how they mainly use end-to-end tests when testing Git. (33:03)

I ask Derrick if there are differences in the way he develops software at Microsoft and the way he develops software for Git. And yes, surely there are differences. The biggest one is that if you work on something internal, it's already decided that the feature is relevant and anticipated. So, you just have to work on making this feature the best it can be. In open-source it's different. Here, everything starts with the need to justify even the smallest change to the community. (35:50)

Derrick explains that there is no roadmap for the development of Git, and that at any given moment, the community and the maintainer of Git decide whether or not a new feature or a bug fix is implemented in Git. (37:55)

Even though the mailing list is actually THE place to be when you want to contribute to this project, there exist smaller sub-communities around Git that communicate also off the mailing list. (40:09)

But, the main decision power lies in the mailing list and the community there.(42:16)

Well, Derrick fills me in how that works at Git. He also explains that no single patch is ever merged without the maintainer (or in seldom situations like vacation a representative of the maintainer) having reviewed the patch. The merge is also always done by the maintainer. (44:34)

I'm curious about how to become an open-source maintainer, and how much authority such a maintainer has. Is an open-source maintainer elected, or selected? How much say does a maintainer have? (46:06)

Well, it seems a maintainer is like a founder of a company or the captain on a pirate ship. Quite some authority, and no election process. The best way to become a maintainer, therefore, Derrick says, is to start your own open-source project including a community. (48:09)

Well, I learned a lot, so I thank Derrick for his time, and he lets me know that if people want to start contributing to Git, they can send him a message. Because, starting to contribute to Git can be difficult and daunting, so he is there to help ease the start for new ones. (49:37)

Links:

Alper’s Twitter account

Kuika the startup they are building

Show notes:

Alper starts by explaining to me why and how he joined this startup. (0:50)

How did they find a business opportunity? (2:07)

How did he choose the right technologies for building this idea? (3:02)

Alper explains to me that he first build the apps they want to build, and then, they build the software that can generate the apps they first build (4:27)

Did the technology they used or the solution they built change over time? (4:52)

What are the engineering methodologies they use at a startup and did that mature over time? (7:08)

- Alper explains to me that they developed and still evolve their methodology in an iterative process.

- They tried all kind of processes and methodologies and always reflected on how it fits their current need.

Alper mentions that how they do things in Turkey is different than how people do things in the Netherlands. Of course, I want to learn more about that (10:06)

Has testing been a part of their software engineering process from the beginning on?

- Well, it has been tricky, Alper says. And it evolved over time. But finally they came up with a great tool that helps them to detect regressions and saves them a lot of time. (11:55)

And do they do code reviews? (14:48)

Are they still doing retrospectives and changing things as rigorously as at the beginning? (16:42)

Alper explains how they always strive to make the processes and practices enjoyable and beneficial for every team  member. (18:16)

Alper says that one of the most important thing a engineer does is to say that he can't do something. That way, the whole team can find a solution. (20:00)

At his startup, engineers are allowed to work 20% of their time on something that interests them. One of his employees decided to build a wedding invitation app. Alper says, this is just such an valuable experiment, because this employee knows exactly how is is to be in the customer shoes. (22:00)

You want to listen to feedback from customers or lead, but at the same time you have to be careful that it isn't misleading, Alper says. (25:16)

Alper learns every day at the startup, but most of the technologies they knew from previous experiences.  (29:36)

So, how did Alper get the first customer? From their personal network, he explains. (37:22)

Alper also talks about their investors and their relationships. In fact, they are very involved in the company. (38:23)

Did they have troubles hiring for their startup and how did they overcome those challenges? (41:45) 

Links:

• More about Leif
• How Automattic Hires Developers
• The Automattic Creed
• Open Positions at Automattic

Detailed Show Notes:

• Leif switched from an academic career to industry (0:50)
• He explains his reasons for the switch, and we discuss that it is difficult to choose where you want to live when you want to become a professor (2:47)
• Leif got his new remote job in the industry at a startup called IDoneThis (3:20)
• The startup was sold, and the team discontinued, so Leif found himself again looking for a new job (3:50)
• Well, as luck would have it, Life got in contact with Automattic, the company behind WordPress.com (4:09)
• Leif applied and interviewed for Automatic although he wasn't familiar with the company's tech stack (4:40)
• Leif explains the interview process at Automattic (7:03)
  • First, you send an email to [email protected]  (including a resume and a cover letter)
  • If you are invited for an interview, you get invited for a slack chat (a screener) where you talk about your background and your skills
  • Then, you get invited to do a small project which takes 4-5 hours over a week. It's a small project with concrete instructions that you must follow. For example, improve some parts of a feature.
  • If that works out well, then, you are invited to do a trial, where you work alongside an Automatic team for a period of 1-3 months for ~10 hours per week. This trial is paid with 25 Dollars per hour.
• Leif fills me in that you aren't working alongside your actual team. The team you are then hired into can be a different one, but you work with an actual team at Automattic and on an actual project. So, if all works out well, your code will be used in production. (9:40)
• Leif describes the tech stack of Automattic, and which skills and technologies you must possess to be able to apply for a position. (10:40)
  • Leif says that the projects at WordPress are very diverse. The tech stacks and the tool chains are therefore very diverse as well. One of the critical skills for any engineer at Automattic is, therefore, the willingness and ability to learn.
• Leif moved within the company and worked on very different projects. Each project you can learn something new, he says. Not only because of the diverse tech stack but also, because each project might serve a different customer base and have a different purpose. (12:20)
• If you want to move to a new project or team, you send a private message to Matt, the founder, and he helps you find a new place within the company (13:01)
• Leif rationalizes that at Automattic, you usually aren't communicating per email. No, they use either chat systems like Slack or internal WordPress sites to communicate and keep track of everything (14:00)
• We talk about how communication processes and channels might differ from a non-remote and a remote company. I wonder, is Matt actually replacing some of the water-cooler conversations you would have at a non-remote company? (14:32)
• Another topic I want to discuss with Leif is how engineers at Automattic keep in contact with other employees if they aren’t in the same building? How do they "hang-out" together? Is there a place in cyberspace that they usually meet at? (15:00)
  • People connect and stay informed through weekly calls, one-on-ones calls, and company-wide town halls that are held once a month
  • Each team and each larger project have its own blog, where you can find all information about everything you have to know
  • Two times per year, each team meets, and once per year all Automattic engineers meet and make a connection with each other.
• Leif walks me through the engineering processes and tools look like at Automattic (17:18)
  • Again, as the tech stack is so diverse, also the processes and tools diver from project to project
  • Some are using Git; some are still using Subversion. Obviously, something like this hugely impacts how the whole engineering process looks like.
• Is Automattic planning to consolidate its technologies and tools? (19:37)
  • Leif clarifies that because they are an open-source company, it's not that easy. Consolidation isn't something you can just put on the agenda. First and foremost, the goals of the company have to align with the goals of the open source project. So only if the open-source project would move from Subversion to Git, Automattic could move as well.
• We discuss how having open source as the foundation of your company creates some tension between the goals of the company and the open-source community. But, embracing open-source also changes the whole company values. Leif describes how transparency is the basis for everything at Automattic. Transparency is reflected in communication and the decision, and although it might not directly influence how people develop software, it hugely impacts the company culture. (20:43)
• Automattic grew quite substantially, so I ask Leif if the culture of the company evolve and change as well?
  • Yes, of course, says Leif. But on the other hand, they still hold on to their main values. The Automattic Creed, a sort of gospel that describes the main values and mindset of the employees of Automattic, helps steer the employees in the right direction.
• Leif reads the Automattic creed to me (25:04)
• I wonder if Automattic has something similar to the Automattic creed when it comes to their engineering processes and practices such as testing or code review? (26:28)
• Leif explains how testing works at Automattic. 26:38
• But what about test coverage? Does Automaticians care about that? Leif says no, because it feels like one metric isn't a healthy indicator. (27:36)
• How does Automattic use code reviews and what does Leif think about code reviews?  (30:08)
  • Leif explains that every code change is looked at by at least one other colleague.
  • Code reviews are very fitting to the learning culture of Automattic. It's highly appreciated engineering practice there.
• I wonder how they ensure – especially at a remote company with many different timezones – that code reviews are looked at in a timely manner. At Automattic, Leif says, they use Trello to track the progress of code reviews, but in addition, they also use a slack app called "the stick" that reminds people if they haven't looked at their code reviews. This normally ensures that you do not have to wait too long for code review feedback. (32:18)
• How does the production process look like, I wonder? And how long does it take to deploy to production? (34:12)
  • Leif says, after review, it's just a merge and a deploy. All is all automated. It's one press of a button. For a few projects, you first might have a staging area for some manual tests and deploy it afterward.
• How do Automatticians handle technical debt? (36:12)
  • Leif explains that they try to move fast, and therefore might create more technical debt than desired. But, once a quarter, they have one week, in which every engineer works on reducing technical debt. Because this is scheduled and expected, they can reduce technical debt and improve the code quite substantially during those times and keep technical debt at bay.
• Another topic I’m interested in is how people at Automattic get assessed and how they get promoted? (39:50)
  • Leif describes that at Automattic, they actually have no titles and that switching from an engineering role to a manager role isn't considered a promotion. Somehow promotions and pay raise work quite different here. I like it.
• How diverse is the technical workforce at Automattic? (44:56)
  • Leif says also Automattic isn't as diverse as they want to be. They struggle with similar problems other tech companies struggle with. But they do actively work towards getting more diverse. How? Well, they are present at events with diverse set of participants, they hire without requiring you to show your face, and by having a very hiring committee that consists of at least 50% women.

Links:

• Hashnode – the developer community
• Syed Fazle Rahman, Sandeep’s co-founder
• Hashnode’s tech stack
• Remote – book from Basecamp
• Accel – the venture capital (VC) firm
• AI Superpowers – Book on how China uses AI

Highlights and overview for you:

• The first 30 minutes: the entrepreneurial journey
• Starting from 26:00: we talk about the development processes
• How and why Sandeep started his developer community (1:00)
• How he met the investor firm Accel and asked for funding (5:54)
• How he seeded and kickstarted the community (11:27)
• How they spend time building a different pivot system – blockchain-based community (14:43)
• How focusing on the wrong things led them down the wrong path. The friendly community wasn’t existent anymore. (21:15)
• Sandeep explains what it means to be working with a VC firm (23:17)
• Does Sandeep feel like an expert for software development? (26:09)
• Sandeep’s experience with Next.js and MERN (Mongo, Express, React, Node) tools? (27:05)
• How does their development process look like? (28:55)
• How do they check for site reliability and security issues? (32:14)
• Do they run static analysis tools? Do they measure test coverage? Which testing practice do they follow? (33:48)
• Why do they run a remote company? (38:29)
• What about their DevOps process? Who has access to the production server, and how does deployment work? (42:13)
• How do they deal with technical debt? (44:27)
• Which books is Sandeep reading currently? (49:18)

All questions by McKayla:

• Sandeep, you’re running a developer community, are you a developer yourself? (0:50)
• So how did you become a developer? What was your way? Are you a self-taught developer or did you go to university? (1:00)
• Did you have the urge to start your own company already during University or did it just come later? (1:45)
• And, what was your first-day job after college? (2:40)
• And when you started Hashnode, did you do that full-time immediately, or was that as a side project again, so in addition to your nine to five job? (3:11)
• So how did you decide which technologies to use? How Hashnode, you know, this community should look like? And how did the whole process start? (3:45)
• And did you choose that tech stack because you wanted to make progress really fast and because you knew those technologies very well from your previous jobs and side projects you built while at university? (5:07)
• How did you validate the idea of Hashnode? (5:54)
• Can you tell me a little bit more about Accel, the VC firm? (7:18)
• Was Accel the first firm that you ask for money and pitched your idea, or did you also try somewhere else? (7:46)
• Was it sort of a smooth ride after talking to Accel or have there been ups and downs before you actually got they funding? (8:30)
• After you pitch your idea, do you just wait or ping them multiple times? (9:27)
• Do you have an idea of how many people used DevMag after the Producthunt launch? (10:50)
• How did you know to kickstart the community from scratch? (11:27)
• So your focus was really on building the community and not the system anymore, right? (12:49)
• Was your first hire a community manager? (13:33)
• How did you find your first employees? (14:09)
• Are the same people still at your company or have you had to turn in your employees? (14:36)
• What is a blockchain community? (15:42)
• Why did this idea fall apart? (16:27)
• OK so that’s actually another sort of pivot of your company, right? From this Q&A style website to blogging functionality for developers. So how is that going? (17:47)
• Did you raise money for that as well? (19:09)
• What’s your vision for this Devblog? What should be the end result? (19:18)
• And for some of the monetization strategies that you brainstorm is there the blockchain coming back? (19:42)
• With all those pivots, have you still been able to keep this 70-30% split between development and community management? (20:06)
• And in these six months that you stopped attending so much to the community what happened? (21:19)
• Does the venture capital (VC) firm give you some feedback on big decisions? (23:17)
• Do you have to ask the VC firm for permissions for big changes that you want to make? (24:16)
• Does the VC firm also have opinions about the software development side of the project for example best practices you should follow or which technologies you should use? (25:17)
• Do you feel like an expert for software development? (25:57)
• Which technical decisions were really good decisions? (27:05)
• How much of the codebase was really rewritten? (27:56)
• So how does your development process in general look like do you do testing or code reviews? (28:53)
• And so, there’s at least one person that has to look through the code review? (30:41)
• And it doesn’t matter who that is? So, if that person says that it looks fine to me than you can actually push it to production? (30:45)
• If they push it to production and there are any bugs how would they revert it? (31:11)
• How can a user report a problem? (31:41)
• How do you address site reliability issues and security related issues? (32:14)
• Something else I wanted to talk a little bit more about is testing. Do you follow some testing methodology, like test-driven development or is that up to everybody on the team to decide? (33:48)
• Do you do Test Driven Development (TDD)? (34:19)
• And do you have something like code coverage to know if you’re covered enough of the code? Do you use metrics like that? (35:31)
• Do you use other static analysis tools? (36:27)
• And why did you stop using static analysis tools? (36:44)
• So, is this your way of reducing the overhead while you just figuring out the features and what the product will look like? (37:57)
• So, a little bit before you told me about the offices that you actually got an office with the VC funding, but that you are remote. What’s the story behind that? (38:29)
• And why did you decide to go from being two people in an office to hiring all over the world and working remotely? (39:41)
• Did you adjust the way you work or the tools for remote development? (40:48)
• And have you ever met your two European employees already? (41:46)
• So especially remote work is really built upon trust. So as I can imagine at the beginning you have to put a lot of trust forward, how was that for you? (42:13)
• So, one of the other things I wanted to talk to you about is your DevOps and your deployment strategy. Has everybody access and the right to deploy to the production or is there some specific process you follow? (42:54)
• Do you have a specific time that you deploy to production? (43:50)
• How do you deal with technical debt? (44:27)
• Do you have rules or processes or tools that help you not to introduce new technical depth? (45:24)
• So you say you’re having no hard deadlines. Would you describe your way of working sort of an agile way working? (46:21)
• So, if you would hire now let’s say, two other people, what would their roles be? (47:25)
• What’s the key metrics that you think help you go in the right direction? (47:52)
• Is there some budget that people can spend like on books or conferences to learn? (48:34)
• What are the books you are looking forward to reading? (49:18)
• Do you have some ideas on how AI can bring your developer community to the next level? (49:42)

**Links: **

• Find a position at Microsoft through Microsoft's careers website
• Scott's blog post on feeling like a phony
• Rethinking how we interview in Microsoft’s Developer Division
• Website for newbies in open source: firsttimersonly.com
• Scott's productivity tips and Scott's talk about productivity

Shownotes:

To allow you to find interesting places here are the beginnings of some conversations:

How and why Scott started to work remotely for Microsoft. (1:25)

When does he have to be at the office? Scott talks about which situations merit a face to face meeting. (4:20)

Does Scott think you can you get a remote position at Microsoft, and how? (6:20)

Does Scott travel all the time? (5:20)

Then, Scotts explains how you can land a remote position at Microsoft (6:35)

Scott says Microsoft careers website hasn't caught up with remote work, but around 22% of the position for the developer division (aka Visual Studio) are remote.

How should we overcome imposter syndrome and feeling like a phony when we apply for a job (7:45)

How you can negotiate your way into a remote position. (8:30)

Is Scott hiring right now? (9:40)

Which interview questions would Scott ask a programmer or product manager? Well, when interviewing, Scott looks for "systems-thinking" skills. He says, everything else can be taught. (11:30)

I want to know that you understand systems thinking and how systems work together. And the recognition that there are systems. (Scott Hanselman)

John Montgomery - rolled out a interview system. You can read more about it here. Basically now, as an interviewee, you work on larger problems and solve them as if you are a consultant. You get to work with the people that work on such a problem. Scott says, we interview you as if you are a person that can help answer this problem, but you do not have to have the answer to the problem right away. (12:35)

Scott says we have to recognise that not everybody does their best work in high pressure situations. And an interview is a high-pressure situation. So, how can we make a interview more comfortable? (13:50)

Scott talks about preparing people and helping people with imposter syndrome feel more at ease at an interview (15:00)

When interviewing for a product manager position, Microsoft developer division (aka Visual Studio team) shares the interview problem before so you can prepare yourself. Scott walks me through such an interview. (16:12)

• You get an actual problem the team wants to solve.
• You also get some data, mockups, costumer data
• The team works with you together to solve this problem, because they want to know how it is to work with you.

Scott explains which kind of interviews there are at Microsoft (17:05)

How can we hire diverse people if we are at the same time looking for cultural fit? (17:35)

Scott talks about how to handle people that think differently, and why people think differently (19:30).

I talk with Scott about his website for newbies in open source, and Scott explains how we can mentor and help newcomers in open source (22:10).

The best way to get people involved in open source is small stuff. Get them working on docs, get them doing tests. Help them do things so they can have an early win. (Scott 25:10)

How can Scott be so productive? What is his secret sauce to productivity, and what is his advice for you to increase your productivity? (26:40)

Has Scott had a master plan to be as successful as he is today? (30:25)

Scott answers a question from a listener on the importance of  DevOps as a engineering practices and wether companies should invest in this practice or not? (32:20)

Shownotes:

To allow you to find interesting places here are the beginnings of some conversations:

We start with how she found herself working remote for CodePen. (1:35)

How it is for Cassidy to working remotely for CodePen (3:15)

What is Cassidy's responsibility at CodePen (6:11)

She is responsible for changing their web application from Ruby Rails and Redux to Apollo and GraphQL

Cassidy talks about how she interviewed with CodePen (9:40)

How the team learns a new technology together as a team (13:20)

CodePen's inclusive environment and women in tech (15:45)

Why does Cassidy spend time on making jokes and funny videos (19:50)

How does Cassidy approach problems? (24:15)

How do they communicate in a remote team? (27:00)

Do they use Code Reviews at CodePen? (29:35)

Cassidy explains that they also invest now more into testing (31:30)

How are decisions done at CodePen? Who decides which features are delivered? (32:15)

Cassidy talks about how they covert CodPen to a more consolidated state using React and Appollo (38:15)

We talk about if you should re-write your code from scratch? (44:15)

CodePen is rewritten piece by piece, reminding Michaela about how Slack UI was modernized.

Now we talk about Cassidy's side projects and how she integrates that into her life (45:50)

Why she isn't a developer evangelist anymore (46:30)

What is up with Cassidy and her keyboards? (48:45)

Cassidy's advice for others on side projects: figure out why you do that (51)

A song that stuck with her and has some solid career advise (52:30)

Lyrics:

The day is short.
The night is long.
Why do we work so hard, to get what we don't even want?

(From the song: The Day Is Short - Jearlyn Steele)

Career advice: You should know what you like and what you dislike (55:00)

Rebecca Gracia: When you build your personal career or your personal brand, it's just as important to know what you like as it is what you dislike.

Links:

• Cassidy's talk about converting CodPen Side.
• Cassidy's website
• Slack engineering blog article on modernizing the UI at Slack

Hello and Welcome to the software engineering unlocked podcast. I'm your host Doctor McKayla and I open you the doors to software companies such as Microsoft, Google or Facebook. But also to smaller startups such as Hashnode, Bitmov or Automatic.

I talk to experienced developers from different companies about how they develop software.

How did they come to where they are today?
How is it to be working at their company?
Which software engineering processes and best practices do they follow?
Do they do code reviews?
Do they have automated tests?
And how do they assess the productivity of the team or an individual developer?

My guests share with you their personal stories and their believes and values when it comes to software engineering. We talk about the companies tech stack, processes, and tools but also about mindset and culture.

Finally, we dig deep to really understand the recipes for success.
How do those teams and companies manage to build maintainable, scalable and reliable software people love?

Find out together with me in the software engineering unlocked podcast.

Subscribe today. We launch soon!

How do those teams and companies manage to build maintainable, scalable and reliable software people love?

Find out together with me in the software engineering unlocked podcast.
Subscribe today. We launch soon!