Greg Dubicki

Probably I am not the only one that tries to find some spot here and there to do a bit of reading (specially if you have 80 tabs open with "Save for later" articles 😅 ). In the IT field, being able to "catch up quickly", "learn quickly" and "solve quickly" is seen as a must to stay in the sector for the long run. To be honest, it is overwhelming. The constant focus on "quickly" can make us forget that real learning and problem-solving takes time and effort. This has deeply bother me for quite sometime and even make me feel unproductive, blocked to finish writing / creating things I had in mind for a while because I am already late for it. But when I take a step back and look at everything I've actually done, I realise I have been doing way more than I give myself credit for (specially given the amounts of hours a day has). It's just hard to see that when you are struggling in the grind. And honestly? It’s exhausting and confusing 🫠 It was a good timing then that Today I ended up with this article from the Hacker Newsletter: https://lnkd.in/dBKG7v7K and something resonated there: "I want to know everything, immediately, quickly. Since this is not humanly possible, I end up doing nothing." "You find yourself in a quest for productivity, feeling productive because of the quest, but not really doing any productive work." "Difficulty concentrating, lack of focus, inability to understand what I read, stress, anxiety. I see these kinds of complaints from many people lately, and in my opinion, our biggest common ground is digital content consumption." And avoiding, like the author, to go against that article, I also do not have an advice, but just leaving the article there for your own reflection on this. Slowing down, taking a break, and letting yourself process what you already know can be more valuable than rushing to consume the next thing. 🌱 Give it a read if this resonates with you. Ask yourself what would slowing down look like for you? I'm trying to figure out for myself right now

36

Developer Experience is still a problem! I listened to this podcast https://lnkd.in/eZPvJnGE on how LastPass tries to make local experience much easier in the area of microservices. They went from the usual suspect of Docker compose but it requires you to build Docker images before being able to run things. Then they went to local kubernetes but it adds another layer and it doesn't help with the extra Docker build step. They decided to use nix which is Docker without Docker, universal package manager. This is something I looked at when working on codefly agents. One goal of codefly is to provide great Developer Experience, a developer starts any service, it will run any dependent services, do all the networking, and even provide hot-reloading for languages that don't have it (golang for example). I found nix to be too complicated so I am relying on Docker and spent quite some time getting that right: you really don't want to start/stop containers all the time and it's actually not that trivial to start and stop processes inside a Docker container. But the pain is worth it: - dependency is minimal, Docker is OK, nix is another story - performance hit is minimal since we try very hard to keep the containers around And agent can also use local stack if available. The philosophy of codefly is that your code needs some "co-pilot" for everything from setup, package maintenance, to networking, Docker build, kubernetes manifests. We do all the annoying stuff so you can just focus on writing code, writing tests that can depend on your full stack without any change of code, or mocking -- just that is a game changer and that's it. We take care of all the painful stuff so you can do the fun stuff!

1

Supercede programmers at Lambda Days conference in Kraków, Poland 🇵🇱 I thought I would win the most-appropriate-tshirt contest, but I think Luke has the edge on that one. I gave a quick lightning talk on primitive obsession in persistent types. Long story short: you should be using `checkMMap` liberally in Yesod forms, and your persistent types shouldn’t contain a load of primitives. Otherwise those primitive values float through your system and there are many more places for things to go wrong. #haskell #functionalprogramming

34

Many of us are working on exciting projects but only few succeed. During my attendance to two European Ruby conferences in June, I had the opportunity to ask top Ruby developers this crucial question: why do software projects fail? These are some great insights they shared on common pitfalls, unexpected challenges, and lessons learned from project failures . Watch my full video on my YouTube channel for more in-depth insights and discussions: youtube.com/@tillcarlos

6

☕ The Coffee-Driven Code Review Manifesto: A Sleep-Deprived Guide to Excellence [Everyone talks about clean code, but let's be honest - most of our best reviews happen after that third espresso shot] 🌅 6 AM: First Commit Code looking pristine Tests all green Documentation spotless Reality: Haven't written a single line yet ☀️ 9 AM: The Morning Stand-up Revelation "Wait, did I just promise to deliver this by EOD?" Frantically opens IDE Types while drinking coffee Spills coffee on keyboard Git commits anyway 🌮 12 PM: The Lunchtime Code Review PR Comment: "Interesting choice of variable names. Is 'pizzaTime' really the best name for a payment processing function?"  Me: "I was hungry when I wrote that..." 🌙 5 PM: The Final Push git commit -m "Fixed everything (hopefully)"  git push origin please-work  git prayer --recursive 📊 Our Revolutionary Metrics: Bugs Found vs Coffees Consumed (1:1 ratio) Time Spent Reviewing vs Time Spent Making Memes About Code Number of "LGTM" Comments That Actually Meant "I Trust You” 🎯 Pro Tips for Sleep-Deprived Reviews: If the code works on the fifth try, it's probably production-ready Comments like "Magic. Don't Touch." are perfectly acceptable documentation If you can't explain your code, blame it on the keyboard 🤔 The Real Code Review Checklist: Does it work? No one knows why it works But it works Ship it! 💭 Question for fellow night owls: What's your record for most consecutive hours staring at a PR before realizing you were looking at the wrong branch? #CodingLife #TechHumor #SoftwareEngineering #DeveloperLife #CodeReview #CoffeeDriver Development #TechMemes

2

Hey! You! #GOTOEDADay #Warsaw is only one month away! Do you have your tickets yet? Now is the time to register -> s12d.com/eda-warsaw Not sure what it is? EDA is event driven architectures. This is how companies like Amazon, Lego, CapitalOne, RyanAir and so many others build large-scale distributed applications that are resilient as a whole, to a failure of the parts. These companies know that, "everything fails, all of the time" and they use EDA to survive and thrive when those failures happen. We have gathered some of the experts from AWS and the industry to come and speak at this event. Here what works and where gotcha's happen and how to deal with them. If you are part of an underrepresented group be sure and see our inclusivity grant (https://lnkd.in/gYR9YD6K) If you are a student and would like to come but cannot afford it, DM me, I can help! If you are anyone else that would like to come but finances are an issue, DM me, let's chat! Bottom line: we want you here! Register: s12d.com/eda-warsaw

17

1 komentarz

How many of your supposedly internal-only backends are serving critical end-user traffic? Probably more than you think! Most frontend services have many transitive dependencies, and understanding these dependencies becomes increasingly difficult as your system grows in scale and complexity. As a result, it becomes exceptionally tricky to ensure that internal-only backends are fully isolated from end users. Google uses a common infrastructure platform for almost all of its services, internal and external; this provides for a message-passing mechanism common to all of these services. One outcome is that systems engineers can build accurate dependency maps of services; and that we can ensure new services only depend on other services at the same level or higher in the dependency stack. Risky dependencies — in this case, dependencies which place internal-only backends on the critical path for end users — can be a source of major production outages, because the internal-only backends do not generally have necessary reliability or safety guarantees. For example, you might have an externally-visible service that requires high levels of availability and performance, and this system has an indirect dependency on a backend with no availability or performance SLOs. At Google, we found success preventing major and huge outages by clustering services into categories with distinct properties, clear perimeters, and limited blast surfaces. The properties will depend on the guarantees we want to enforce. In this article, we use Google Maps to demonstrate how risky dependencies proliferate in complex systems, and then showcase how clustering Google Maps services into just two categories ("Internal" and "External") can prevent major and huge serving outages. We also outline how OpenTelemetry is used to identify violations of this clustering, which can be fixed before the violations cause a major serving outage. This article is based on a talk at SREcon EMEA, which you can see here: https://lnkd.in/e54b6G6p.

1

Gave a talk at work on "Dependencies" today, trying to externalise and make explicit some of the background awareness that shapes my everyday practice as a software developer. It takes time for this awareness to develop. I remember the first time someone talked to me about how Gradle uses a topological sort over a graph of dependencies to determine a build order for tasks, and what a revelation that was. I remember the first time I was shown how to get IntelliJ to scan a Java project for cyclic dependencies between packages, and coming to understand why one might want to avoid them and how to unpick them if they arose. Now DAGs (directed acyclic graphs) are a comfortable piece of my mental furniture, but I don't know that more junior developers are often directly introduced to them - they might come up as a data structure with associated algorithms in CS courses, but is it explained that they're fundamental to the way compilers and build tooling assemble working software from many related pieces? Many developers are aware at some level that transitive dependencies can balloon out into bloat (and an ever-expanding attack surface for vulnerabilities), but how many can articulate this clearly? A large part of my practice as a Principal Engineer is mentoring individuals and looking out for knowledge gaps in teams. It can be hard to recover a "beginner's mind" and remember what it was like not to know (or to be only vaguely aware of) something that became second nature to you over a decade ago, but it forces you to make your implicit knowledge explicit - which also gives you opportunities to reflect on it. Teaching is learning: you go back and retread old paths, and are confronted again with long-forgotten questions. Like everyone at the moment, I wonder what the impact of LLMs is going to be on the way developers acquire the background awareness and instincts that guide accomplished practitioners. Will they help to make implicit knowledge explicit, or will they paper over gaps in knowledge and obstruct the process of learning?

12

2 komentarze

Why Some Companies Have Severe Hiring Problems If you are offered a prize for selecting the white bean among 10 black beans or 1000 black beans, which would you choose? The answer is obvious in the case of beans, but apparently far from obvious in the case of selecting a good, senior mobile app developer. Why? A major reason is that many companies put too many restrictions on their job descriptions. The most common detrimental restrictions are 1. W2 only, no C2C 2. Work onsite only, no remote. Restriction 1 is restrictive because of money, I guess. If W2 employees are seen as cheaper in the long run, then companies will hire only W2. This is a bad way to save money, because many senior developers will not work W2. If you want to save money, hire a single, small team of senior developers to develop your app on Android and iOS both by using Compose Multiplatform, instead of hiring two large teams of mostly junior developers to separately develop iOS and Android apps. Restriction 2 is probably the worst. If you want to hire a really good senior app developer in Plano, TX, for example, why restrict the talent pool to those devs living within 10 miles of your office or transient app developers who can relocate hundreds of miles at the drop of a hat? How many good, senior devs fitting these requirements and who are not working do you think there are in this tiny talent pool that you have created because you require people to work onsite? Onsite work requirements generate poor productivity. Just a couple of days ago I discovered at about 5 PM that I needed to do three or so Android builds requiring 30 minutes or more. If I was required to work onsite, those builds could not be done until most of the next morning. Working remotely, I was able to complete the builds by about 10 PM that day while watching a baseball game. Next day, I am ready to be productive immediately, instead of wasting an entire morning just because I am required to be onsite. I read somewhere that when everybody was working remotely because of Covid, many companies found that some devs were not getting the job done working remotely. So the solution these geniuses came up with was to require every dev to work onsite. News flash: those nonproductive remote devs are still going to be nonproductive onsite devs, but now all your remote, productive senior devs will lose productivity when you force them to work onsite.

2

I’m still a Rust neophyte, but this is an interesting post about async and complications it introduces in a work-stealing runtime where any task can be scheduled on any core at any await point. Things are much simplified if you assume a “share nothing” architecture where once scheduled onto a thread, the task (and its descendants) is guaranteed to never migrate off that thread. Reminds me a lot of the Seastar C++ framework used in ScyllaDB.

8

Scenario showcasing how Bitbucket can be utilized in a different context: Open Source Project Collaboration : Imagine a team of developers contributing to an open-source project hosted on Bitbucket. Here's how they might utilize Bitbucket's features: Repository Forking : Developers interested in contributing to the project can fork the main repository to create their own copy. This allows them to work on changes independently without affecting the original project until they're ready to submit their contributions. Feature Branches : Each developer creates feature branches in their forked repository to implement specific features or address issues. They follow best practices such as creating descriptive branch names and keeping their changes focused on a single task. Pull Requests and Code Reviews**: Once a developer completes their work on a feature or bug fix, they submit a pull request to the main project repository. Other contributors review the code changes, provide feedback, and discuss potential improvements through comments on the pull request. Collaborative Testing : As part of the code review process, contributors may suggest additional tests or improvements to existing test coverage. They may also run tests locally or utilize Bitbucket Pipelines to ensure that the changes pass all necessary tests before merging. Integration with Issue Tracking : The project may use Bitbucket's integration with issue tracking tools like Jira to manage feature requests, bug reports, and task assignments. Contributors reference relevant Jira issues in their commit messages or pull requests to provide context and ensure traceability. Maintaining Code Quality : The project maintainers enforce coding standards and quality guidelines by reviewing contributions and providing feedback on code style, documentation, and adherence to project conventions. They may also use Bitbucket's code insights to track code complexity, code coverage, and other metrics. Community Engagement : Bitbucket fosters community engagement through features like discussions, wikis, and project wikis. Contributors can participate in discussions, share knowledge, and contribute to project documentation to help onboard new users and developers. Version Control and History : Bitbucket serves as a centralized repository for the project's source code, providing a complete history of changes made by contributors over time. Developers can easily track revisions, revert changes if necessary, and explore the evolution of the codebase. In this scenario, Bitbucket enables distributed teams of developers to collaborate effectively on an open-source project, regardless of their geographical location or organizational affiliation. By providing a platform for version control, code review, and project management, Bitbucket empowers contributors to work together seamlessly and drive the continued development and improvement of the project. #Bitbucket #Jira #Atlassian #Development #jiraAdmin

16

This is an excellent blog comparing the streaming ingest of row-level operation comparison among the LakeHouse formats. https://lnkd.in/dsCN66_5

1

WARNING ⚠ : Are you about to design or work on a microservices project? If so, you really need to read this first. I will be publishing a series of articles about the dark side of microservices projects, and how some tiny design mistakes can grow into huge problems 🌋. My point of views are up for debate. I'm not saying I'm right, rather I'm showcasing some of the problems I went through. If you have an opposing opinion please share it with me as these discussions can help both of us learn more 📚.

6

Here are the slides for my GopherCon.EU talk: How to Win Frames and Influence Pointers https://lnkd.in/d7byRQfu #gopherconEU #golang

72

4 komentarze

When I first started with Clojure, it essentially meant working within the JVM or JS ecosystems, with all their benefits and drawbacks. Since then, the landscape has changed a lot. Babashka came along, effectively replacing Bash and Python for me in 90% of use cases. Then there was ClojureDart, making mobile app development much easier—something that was never a walk in the park with Clojure before. I also discovered Basilisp, which compiles Clojure into Python, expanding its reach even further. Scicloj is another great project, with Daniel Slutsky pouring a lot of energy into it. Today, I wouldn't hesitate to use it for analyzing complex data, unless I specifically need a library that's only available in R or Python. And now, with Jank from Jeaye Wilkerson (who has years of experience building game engines for EA), we’re about to be able to use Clojure with C++ as well. This opens the door to high-performance, native applications. Clojure is (becoming), in my opinion, the most versatile modern language out there.

15

1 komentarz

I'll be talking about building future-proof React applications on the 30th of May in Bucharest. Everyone needs to have a set of principles they follow so they don't have to think about every problem from scratch. I'll tell you how I've been building React applications for the last 8 years. What works. What doesn't. What to focus on to make sure you don't have to rewrite your application every year. Because programming is about solving problems. But engineering is about maintaining those solutions over time.

100

3 komentarze

I could not agree more. Recent articles about "ghost developers' based on the number of GitHub commits reflects an incorrect perception of how hard software developers working in different roles. I was also annoyed by the notion that somehow, there are 10% of developer's 'coasting' and getting paid hundreds of thousands. This happens in all industries not just software development. https://cstu.io/d41234

3

2 komentarze