Afleveringen

  • Anton, co-founder of Codeborne, and I sit together to discuss some of the problems in software engineering - pull requests, microservices, testing, refactoring. Check out annotated chapters below for more details.

    00:00:00 Intro

    00:00:00 Sneak peek

    00:00:49 Episode overview

    00:04:28 Anton's intro, background

    00:06:37 Anton founded Codeborne: TDD and pair programming: following extreme programming principles

    00:08:57 Agile is about short feedback loops

    00:12:09 Under-engineering vs over-engineering

    00:15:29 Tech debt and testing: engineers don't handle tech debt well enough

    00:17:45 Lack of refactoring is a big problem

    00:18:14 Problems with pull requests

    00:27:00 Problems with squash merge

    00:27:30 Good commit messages are essential

    00:31:09 Good code is easy to change

    00:34:34 Pair programming is continuous code review

    00:36:11 Daily code review with a whole team

    00:48:44 Microservices: be careful

    00:59:23 Book recommendations from Anton

    01:00:38 Wrap up



    This is a public episode. If you would like to discuss this with other subscribers or get access to bonus episodes, visit log.mapforengineers.com
  • Lauri Koobas, ex-Microsoft and currently Head of Data Platform at Bondora, shed insights on data engineering - from early startup to scaling.

    We mostly focused on analytics and building data warehouse - real-world challenges from both data engineering and software engineering sides. We also discussed GDPR and PII challenges when dealing with data.

    You can find video version on MapForEngineers YouTube channel: https://www.youtube.com/@mapforengineers

    Annotated chapters in timeline:

    00:00:00 Sneak peek of episode

    00:01:21 Episode overview

    00:02:44 Introduction, Lauri's background

    00:20:48 Starship robots: huge amount of data there

    00:23:37 Data lake, data warehouse, data lakehouse

    00:26:44 Devil is in the details: timestamps, texts, character sets...

    00:49:44 Moving data from prod to data warehouse

    00:53:09 Analytics tools: PostHog, Amplitude, Redash, Databricks

    01:00:15 Analytics tools vs real-time monitoring like Prometheus/Grafana

    01:04:15 Usability matters: each tool for its job

    01:06:38 Startup grows: needs in data analytics

    01:11:09 Multiple data sources: when data warehouse really begins

    01:19:55 Data and (de-)coupling: software engineers should not be blocked by analytics

    01:22:51 Data ETL

    01:24:59 Changes in data model: multi-phase migrations

    01:29:38 Change data capture, incremental imports

    01:34:21 Should analytics have new data in real time? Maybe not?

    01:39:02 Importing data into DWH through business events

    01:43:37 When DWH subscribes to business events, data model can evolve freely

    01:47:16 Quick recap what we discussed so far

    01:52:25 GDPR and Data Compliance: start early

    01:56:05 PII data: know exactly where you store it, control it well

    02:03:37 Lauri's books recommendations on data engineering - Kimball

    02:07:18 Lauri's podcast on data engineering, in Estonian

    02:08:28 Wrap up



    This is a public episode. If you would like to discuss this with other subscribers or get access to bonus episodes, visit log.mapforengineers.com
  • Zijn er afleveringen die ontbreken?

    Klik hier om de feed te vernieuwen.

  • Carl, staff software engineer at Pactum, shed light on some of the latest AI tools in software development. We discussed v0.dev, continue.dev, ollama, and much more! It was an episode with a lot of useful information and insights! To check all content on Map For Engineers including blog posts, feel free to subscribe on https://MapForEngineers.com

    Annotated chapters in timeline on topics that Carl and I covered:

    00:00:00 - Start

    00:04:05 - Small talk, getting into the groove

    00:08:18 - Carl's background: ex-Pipedrive, now engineer in Pactum

    00:19:44 - Early tools: simple autocomplete and simple prompting without context

    00:27:11 - AI tools with context: Cursor IDE, Continue.dev

    00:43:35 - Cursor IDE Composer - Prompt+Apply to Code Instantly

    00:47:29 - Ollama - following docker philosophy

    00:55:15 - V0.dev - LLM to create frontend components

    00:59:27 - Cursor IDE + v0.dev combination as a workflow

    01:02:23 - Claude 3.5 Sonnet

    01:03:10 - OpenAI o1

    01:04:56 - LLMs vs SQL Queries - still to be solved

    01:08:17 - LLM in TDD and Testing Workflows

    01:16:04 - Focus on engineering fundamentals - LLM does not replace your engineering fundamental knowledge

    01:20:13 - Book recommendations

    01:29:09 - Hosting models yourself - expensive

    01:33:27 - Fine-tuning models

    01:35:33 - RAG

    01:49:50 - Chain of thought

    01:51:46 - vyce.app - GenAI helping with compliance questions

    01:54:25 - Summary of tools we covered so far

    01:58:43 - GenAI vs engineering careers

    02:05:39 - Wrap up with Carl



    This is a public episode. If you would like to discuss this with other subscribers or get access to bonus episodes, visit log.mapforengineers.com
  • I had a pleasure to chat with my friend Joel Mislav Kunst, who is Engineering Manager at Microsoft. We talked about growth in engineering. Some of the topics that we touched upon, with timeline timestamps are:

    00:00:00 - Glimpse of episode

    00:01:16 - Quick episode overview

    00:05:18 - Joel's journey in software engineering

    00:14:55 - Focus on engineering fundamentals

    00:23:34 - Learning from all hard experiences: solving root causes

    00:31:05 - Relationship between engineer and their manager

    00:53:03 - Manager is not your punching bag for complaining: propose initiatives instead, be active

    01:10:55 - Engineer vs manager: fork in career

    01:29:17 - Generative AI in context of engineering career/growth

    01:36:01 - Teaching is essential for growth. Seniors teaching juniors. Knowlede sharing

    01:43:14 - Wrap up

    To get notified of new episodes and blog posts, subscribe at MapForEngineers.com

    For Youtube video version of the episode, check https://www.youtube.com/@mapforengineers



    This is a public episode. If you would like to discuss this with other subscribers or get access to bonus episodes, visit log.mapforengineers.com
  • Ürgo, ex-Wise, joined Wise.com as one of the first 12 engineers or so. As former colleagues from Wise, we had a great chat about product engineering, domain-driven design, and team collaboration.

    I will give a short summary of key takeaways that I got from this valuable discussion with Ürgo.

    1. Work in agency is different from work in a product company

    Work in agency (outsource) vs product company is different for an engineer. In agency, you get a lot of experience with different projects, but you don’t own a product or its outcomes.

    In contract, in a product company, engineers should care about the end product, getting the feedback from users and customers. Responsibilities and impact are on the next level for an engineer in a product company, that you don’t get in a project-based work in an agency.

    2. Knowledge sharing inside a team. Avoid knowledge silos

    It’s important to avoid pockets of knowledge in a team, where sub-groups form, because then it’s hard to have a cohesive team. There are many tools to avoid it, for example:

    * Pair programming

    * Deliberately rotating knowledge among people

    * Working in pairs (not necessarily pair programming, but just solving some problem together) on a topic for a short time (e.g. a week or two). But then switching pairs and topics, to avoid knowledge silos.

    * I wrote in detail about some practices that I employ in Pactum to avoid knowledge silos in the team in the article Values, Principles and Practices in Engineering Team.

    3. Product engineering begins where the comfort of the coding ends

    Ürgo wrote amazing article about this topic, called Product Engineer, available in his Medium.

    Product engineers need to establish frequent feedback loops to get signal from users on the usefulness of what they delivered. This is essential for closing the feedback loop. Once you get learnings, you repeat the process: Learn → Build → Ship → Learn → …[repeat]

    4. Domain-Driven Design: Metaphors are important

    Coming up with metaphors when modelling software is very important. When you come up with a good metaphor, try to embed it into your ubiquitous language.

    5. GenAI in Software Engineering

    GenAI won’t replace product engineers for a while. In fact, product engineering becomes even more essential than just coding. Coding is just a tool, a means to an end. Product engineering skills will be ever so valuable - to understand which product to build, to iterate, to learn from your users and customers, to be creative. Product engineers will leverage GenAI tools to automate non-interesting tasks (e.g. creating this next frontend component, if it can be automated quickly).

    ---

    And that’s a wrap! I will be recording new episodes soon. Feel free to subscribe if you found it valuable. Also, recording quality in the next episode will be better.

    For all the content, visit MapForEngineers.com



    This is a public episode. If you would like to discuss this with other subscribers or get access to bonus episodes, visit log.mapforengineers.com
  • I am starting a Map for Engineers Podcast! I am in the process of organizing a first episode with my guest, which will be live-streamed on YouTube :) Will announce more details soon.



    This is a public episode. If you would like to discuss this with other subscribers or get access to bonus episodes, visit log.mapforengineers.com