Zeb Fross

Interesting conversation for those just beginning their careers, in engineering or beyond. Thanks for sharing Andy Greenwell!

3

1 Comment

Pro-tip if you're new to TDD: It's important that things fail first whenever you make a change. This isn't religious dogma - it's an important part of the practice that makes it useful. It's way too easy to get a false-pass. Proving to yourself that your test actually tests something (by purposefully putting the code under test into a failing state) is the best way to avoid this.

19

"Small" things I highly appreciate about Kotlin coming from Java - Chapter 2 𝗦𝘁𝗿𝗶𝗻𝗴 𝗧𝗲𝗺𝗽𝗹𝗮𝘁𝗲𝘀 𝚒𝚖𝚙𝚘𝚛𝚝 𝚓𝚊𝚟𝚊.𝚝𝚒𝚖𝚎.𝙻𝚘𝚌𝚊𝚕𝙳𝚊𝚝𝚎 𝚏𝚞𝚗 𝚖𝚊𝚒𝚗() {     𝚟𝚊𝚕 𝚗𝚊𝚖𝚎 = "𝙹𝚘𝚑𝚗 𝙳𝚘𝚎"     𝚟𝚊𝚕 𝚝𝚘𝚍𝚊𝚢 = 𝙻𝚘𝚌𝚊𝚕𝙳𝚊𝚝𝚎.𝚗𝚘𝚠()     𝚙𝚛𝚒𝚗𝚝𝚕𝚗("𝙷𝚎𝚕𝚕𝚘, $𝚗𝚊𝚖𝚎! 𝚃𝚘𝚍𝚊𝚢 𝚒𝚜 ${𝚝𝚘𝚍𝚊𝚢.𝚍𝚊𝚢𝙾𝚏𝚆𝚎𝚎𝚔}.") } https://lnkd.in/eM9mCxgu No more overusing 𝚂𝚝𝚛𝚒𝚗𝚐.𝚏𝚘𝚛𝚖𝚊𝚝 parameters. No more clunky 𝙼𝚎𝚜𝚜𝚊𝚐𝚎𝙵𝚘𝚛𝚖𝚊𝚝.𝚏𝚘𝚛𝚖𝚊𝚝. It just works. #Kotlin #Java #JVM #String #StringInterpolation #StringTemplates #SoftwareDevelopment -- Mastodon: https://lnkd.in/esH5bUU8 Nostr: https://lnkd.in/eXgvrTZr

8

1 Comment

People tend to believe that there is more of a trade-off between Quality and Speed than there really is. Most of the time, if you’re doing a good job of refactoring and writing tests as you go, the final product doesn’t take any longer than it would have to do it “the hacky way,” if by “the final product” we mean “a system that actually works and does what its users need.” True, once in a while there are huge problems that you can’t tackle right now. For example, maybe the right thing to do is to redesign your application with a whole new data store, but that could take years. You can’t do it right now. That said, _most_ of the problems that users experience with software don’t come from these decisions to set aside these huge projects for later. Most issues come from a series of small decisions that grew over time into a complexity that nobody understood or managed correctly. Often they come from a developer just _feeling_ rushed, like they can’t refactor this right now, they can’t test this right now, etc., when really they do have the time to do it. Let me give a specific example. I once caused a fairly significant production outage at YouTube. I was mid refactoring a very complex piece of code, and I had not written a test at the highest level to make sure all the pieces still worked well together. Had I written the test, the issue absolutely would have been caught. So egg on my face, right? Well, there are two lessons to take away from this, actually: 1. The shallowest lesson here is that one should have tests that cover what one is refactoring. 2. A deeper lesson is this: the function I was refactoring had grown incrementally into a hairball that was basically impossible to understand. Every person who had worked on it (many people) had chosen _not_ to fix its structure over a period of many years. They also had never written a test for its behavior—you couldn’t even look at a test to understand what it was _supposed_ to do. The function was basically Pandora’s Box; some day somebody was going to touch it and cause something to break, and the person who did that happened to be me, because I wrote about 100 changes to it (incremental refactorings) and one of them happened to have a bug. So should I have written a test? Maybe. Honestly, until I went through the process of refactoring it, it was really hard to tell what it was _supposed_ to do in all sorts of various edge cases that it covered. Am I personally responsible for that outage? Of course! But am I the _only_ person who contributed to that outage occurring? No. Every time somebody says, “well, I’ll refactor that later,” and doesn’t, “we really ought to have monitoring eventually,” “I should write some tests some day,” THAT is where most problems start. And the wild thing is—almost always, those problems didn’t have to start! If everybody had maintained the system well as they went, it’s unlikely there would have been any impact to the speed of delivery.

153

24 Comments

Fascinating summary of why Figma decided to move from ECS to EKS (#Kubernetes) here are the four key points that stand out to me: 1. Hiring ECS experts is very hard! I believe this. 2. Using open source softwares, we find that most things nowadays are available as a Helm chart distro, while very few OSS projects support ECS officially. (I understand this viscerally, Helm was essential to my Kubernetes onboarding journey and still is.) 3. Autoscaling - the ECS platform supposedly does support it, but they were not using that feature at all. Why? (Might have to read the source document to understand) this turned out to be very costly, anyway. 4. Logging through CloudWatch, Datadog, and Snowflake also turns out to be very costly. Dynamic scaling is a well traveled road in the Cloud Native community, with projects like Karpenter, KEDA, the built-in solutions like Horizontal Pod Autoscaler... I have never used any of this in anger, but I have studied it and shared it for the KubeCon audience. Does this resonate with anyone else? I too would like transparency into the version of software running and to be able to easily access that information across my clusters. This is a valuable property of GitOps solutions like #Flux when implemented well, but the implementation of a multi-cluster and/or multi-tenant use case is still a challenging one, requiring more than a bit of study to master. Does anyone in shouting distance have good or bad experiences to share with that in mind, on either platform or others? (I'm interested to hear from you!)

9

100% agreed. Bool flags are common with junior developers. But bool complexity explodes: • With 1 boolean flag, you have 2 possible states (true/false) • With 2 flags, you have 4 states (2^2) • With 3 flags, you're at 8 states (2^3) • With 10 flags? A whopping 1,024 states! (2^10) This exponential growth (2^n) can quickly lead to: ✅ Increased testing complexity ✅ More potential for bugs ✅ Harder-to-maintain code Next time you're tempted to add "just one more flag," consider the exponential impact on your system's complexity. Use enums, bitsets, state machines, or other patterns instead.

2

1 Comment

I create custom hooks very often. They’re a great way to abstract complex logic and only export the data the component actually needs to render the JSX. But there are engineers who see non-reusable custom hooks as an unnecessary abstraction. So I wanted to address some of the common criticisms of this approach. 1. They reduce the locality of behavior Locality of behavior isn't equal to inlining code. If it was we would be putting all our logic in a single component. The component still owns its logic by invoking a custom hook built for its purposes. 2. You have to frequently jump between at least two files UI and business logic change with a different pace and most often you will be making visual changes to the component. There's a benefit in not having to understand all the logic in order to make a change to the JSX. 3. It’s more code It's 2 lines of extra code - the function definition and its closing bracket. Oh and the export statement. That won’t break or make your application. 4. In many cases, the hook contains code it doesn’t use. Actually, it's the other way around. In most cases a component owns logic it doesn't use in its JSX and that's a lot more confusing. You will be surprised at how many components use only a piece of state but have 30 lines of code related to it. 5. You have to repeat many component props in the custom hook I'm yet to experience this problem. But if you need to pass all your data to a custom hook, just extract a type and reuse it. Wrap it in an object if you need to. 6. Encourages creating a monolithic custom hook instead of abstracting small, focused, well-named custom hooks If your custom hook has too many responsibilities then it's a sign of bad component design. Split your component into smaller ones and you won't be building monolithic hooks. Simple as that. Hope this clears up some of the questions people have related to custom hooks!

149

35 Comments

A question to my friends, colleagues, and Linked-In associations that are full TDD developers. Folks who consider themselves proficient or have mastered TDD. 1. How long did it take you to to become very proficient (e.g. to start thinking fully test first)? 2. Did you have a mentor or some aid that helped you along the way? 3. What kept you going down the proficiency/mastery path? I'll start: 1. It took me about 3 years to make it a habit and for me to truly embrace TDD and find that it could replace "test after" development. 2. I did not have a mentor. I did not have YouTube or trainings. I had constraints about creating automated tests. I had teammates that were similarly inclined (constrained). 3. I immediately saw the value of automated tests. I struggled with test first getting in the way of me feeling productive (because I was not proficient and in the learning/gaining proficiency phase) with test first. I'd start every day test first and quickly transition to test after, because it was getting in the way of my "productivity and programming...damn it I just want to write the implementation!" At the end of the day I'd reflect and most days realize that writing tests after was so much slower. Slowly, my time spent test first increased. At some point I transitioned to pseudo coding my intended implementation (to satiate my need to "just write the damn code and not be bothered with tests"). More time passed and I realized that my pseudo code was an inaccurate crutch, I ditched that too and would start with a test. There was a period of time where I'd start with a test and get lost in implementing more than just making the test pass (cycles of sunk cost fallacy here, until I learned it's ok to delete and write it later - faster, better, stronger). There were periods of time where I'd forget to run the test first to see it red before making it green. Too many years messing around with mocking frameworks before learning better design. Struggles with testing internal implementation details instead of external behavior. A whole bunch of stuff I can't think of now and am probably blocking out. I stuck with it though and yikes, does it pay off. I can't imagine not doing TDD now. Coding w/o it is like running through a vat of molasses. So much time wasted in the debugger and writing things that my evil programmer monkey brain distracts me with that YAGNI. I'm writing and asking about this because last week I attended a conference where I talked with a fellow TDDer who'd heard me mention that it took me 3 years to become fully TDD proficient and he shared a similar story even though he was much younger than myself (I attribute my slow adoption due to lack of a mentor/coach and training aids like Pluralsite, YouTube, Jon Reid live coding sessions). I'm curious about others mileage on this. I'll add that I am currently 100% on board with TDD. I am also 100% always on the lookout for a new and better way to replace it. That's off topic though.

45

70 Comments

The latest version of Node is now available. Node.js 22 Some of the newest updates include: - V8 JavaScript engine updated to 12.4 - Support for require()ing ESM graphs is now exposed by default - Package authors can now easily allow both CJS and ESM users to consume their package - Added WebSocket client  - node --watch now stable - (A mode in which you can run your node server and it will reload when a change happens to the specified file or path. - Increased the default highWaterMark for streams, providing a performance boost across the board at the cost of slightly higher memory usage. What are your thoughts on the latest Node release and what features would you like to see next? #node #node22 #softwaredevelopment

10

2 Comments

𝐄𝐯𝐨𝐥𝐮𝐭𝐢𝐨𝐧 𝐨𝐟 𝐒𝐨𝐟𝐭𝐰𝐚𝐫𝐞 𝐀𝐫𝐜𝐡𝐢𝐭𝐞𝐜𝐭𝐮𝐫𝐞 1. Monolithic Architecture:   Structure: All application components are tightly coupled into a single unit.   Integration: Both frontend and backend exist within the same codebase.   Challenges: As the application grows, scalability becomes difficult, and maintenance becomes increasingly complex due to the interdependencies of components. 2. Frontend + Backend Separation (Hybrid Monolith):   Structure: The frontend and backend are separated into distinct layers.   Benefits: This approach allows for more flexibility in choosing frontend technologies and decouples the user interface from server logic.   Consideration: While the frontend is separated, the backend may still be monolithic, which can limit the overall scalability and flexibility of the application. 3. Microservice Backend + Monolithic Frontend:   Structure: The backend is divided into independent microservices, each handling specific functionality.   Benefits: This separation allows for better scalability, independent deployment, and the ability to update backend services without affecting the entire system.   Challenges: The frontend remains monolithic, which can still pose limitations on scaling and may create bottlenecks in the development process. 4. Micro Frontends + Microservices:   Structure: Both the frontend and backend are divided into smaller, independently deployable units.   Benefits: This architecture promotes parallel development, technology diversity, and full decoupling of the system, making it highly modular and scalable.   Agility: Teams can work on different parts of the application simultaneously, enhancing overall development speed and flexibility.   Considerations: This hybrid approach, combining microservices on the backend with micro frontends, provides the highest level of independence and scalability. However, it also requires careful planning and management to ensure that all parts of the system integrate smoothly. Conclusion:  The evolution of software architecture reflects a move towards more modular, scalable, and maintainable systems. The choice of architecture should be guided by the specific needs and constraints of the project, such as size, complexity, and longterm goals. By understanding these different architectural patterns, organisations can better adapt to their requirements and deliver more robust and agile applications. Please let me know in comment DId i miss anything ,?

882

26 Comments

You work on a feature in the `my-feature` branch. You have a bunch of new files, modified a handful of existing files, and added a new dependency (NPM package, Rust crate, etc.). Alice, your team member, asks you to review a pull request that contains a production hotfix. Put yourself into that situation and think about the last time a co-worker asked you to review their code while you were deep in the process of developing a new feature. How do you feel? Read my blog post to learn how I review PRs and work on multiple branches in parallel. No more `git stash`, no more missing / outdated dependencies, no more “It works on my machine”. https://lnkd.in/gR7RWXfp

6

3 Comments

Programming challenges are a lazy test to filter for high IQ & ability to code. Making an interview process actually reflect the work you'll be doing takes thoughtful design. So most companies don't bother. Valid strategy if you have enough applicants in your pipeline and a high enough filtering bar. If you're smart enough to pass leetcode questions you're probably smart enough to figure out the actual job. Fire quickly to cover the rest. But it doesn't respect the applicants. It would bother me a lot less if companies admitted this up front. "Hey, we know this coding test has nothing to do with the job. Doesn't matter. We want to see how you think. Here's what qualities we're looking for:"

18

16 Comments

helpful advice

1

I don't know about TDD, but the fact is that test coverage does enable you to do a massive rewrite/refactoring that would otherwise be completely impossible. Want to change everything to squeeze in some better performance? Sure, go ahead if you have enough test coverage. And it doesn't really matter to me if I wrote the test or the code first or not. This is not a religion. But on the other hand, if you need such massive rewrites and refactoring, maybe something else is a real problem.

13

5 Comments

Explore Redis data structures and learn how to use them effectively for caching and storage. Discover best practices to optimize your applications.

4

Observation: 9/10 SWE's quit at “reading the docs”. Cut through the BS with this easy trick: Take action and build. Writing code is 100x easier than the docs make it sound. “Reading the docs” gave me crazy imposter syndrome: -Git -WPF -Kafka -OAuth -Angular -GraphQL -RabbitMQ -Kubernetes In ALL cases, I conquered my fears by building. Except for WPF. I gave up on that. And Kafka, that's for another day. Forcing yourself to build/code/deploy melts analysis paralysis. Then you'll say "oh that was pretty easy". Trust me, we aren't building rockets. Practice AND Study build true mastery.

22

1 Comment

Enums vs Booleans: 🔄 Opting for enums in coding can enhance readability and prevent errors, as they require explicit typing and offer clearer intent than booleans—what are your thoughts on using enums for better code clarity? 💭👨‍💻

3

1 Comment