The entire plot of the Iliad is like one big code review gone bad. You just spent the better part of the week painstakingly building out that killer new feature. In fact, it's some of your best engineering, the unit tests are a work of art, and the function names would make Uncle Bob proud. But not so fast! The next thing you know your work is completely ripped apart by someone more senior. This is what sparked the rage of Achilles! Agamemnon used his opportunity to save the Greek army as a means to assert his dominance over Achilles, rather than leading as he should. Agamemnon took what was treasured by Achilles in front of everyone setting in motion the epic on anger and pride. At one time or another we've all been tempted like Agamemnon when giving a review. So remember, code reviews aren't a means to satisfy our own pride and insecurities about our position. Have you ever been in a code review that felt more like a battle than a collaboration? Let's turn these moments into opportunities to learn and grow with each other rather than using each other. How do you ensure your code reviews are constructive and empowering? "Achilles’ wrath, to Greece the direful spring Of woes unnumber’d, heavenly goddess, sing! That wrath which hurl’d to Pluto’s gloomy reign The souls of mighty chiefs untimely slain;" - The Iliad, Book 1
Michael Blakeney’s Post
More Relevant Posts
-
One of the biggest reasons I love #Go is Go 2.0 in the sense of breaking with the past and no longer compiling old programs will never happen. Ever. That means your code written today will be running after 5, 10, 15 and even 20 years on an up-to-date Go compiler. 👇 https://lnkd.in/dNBrStRs.
To view or add a comment, sign in
-
Wrong question. If you have no design that's unprofessional. If you have tests and no design you are expecting people to read your tests to figure out whether and why your program does what it is supposed to do. That's unprofessional. If you have a design you will want to verify that it is correct and that it was implemented correctly. Most of the time that will be done with testing. So if you have a design for what you did, the question of whether you have tests does not arise.
Senior Software Engineer && Data Streaming Engineer at ATA, LLC | Full Stack Cognitive Science Enthusiast | Servant Leader | Husband | Father
"If you still don't have tests, this is unprofessional" - Marco Pivetta The following is a nuanced response to to this idea in software development, and helped me frame quite a number of things, in trying to answer: is there justification for not having tests? What's your opinion?
To view or add a comment, sign in
-
As your application grows, efficient code minimizes thresholds and maintains the performance. This is something within my projects that I am eager to share. having efficient code is easier to maintain and debug as well, you'll know exactly where to go, and/or where the issue lies. This reduces time and effort required to make changes or fix said issue(s).
To view or add a comment, sign in
-
Software code linters are misunderstood. I had a good conversation with a developer yesterday on this. Linters give developers stylistic errors like: - This line is too long - This function has too many lines - This function is too complex - This module has too many lines When we see an error like this, we take it at face value. We don't ask, "What is this really trying to tell me?" We should ask: - Will the next dev be able to read and understand this logic quickly? - How is this function trying to do too much? - What is this function responsible for? - Does all of this logic belong in this module? The linter is a proxy for good code. It's not a meaningless authoritative rule to make developers' lives difficult. The best developers & dev leaders know when the proxy is working and when it should be ignored.
To view or add a comment, sign in
-
I think most Senior devs agree that juniors should build outside of tutorials But I would add these caveats: 1. Learn good software principles (i.e. anti patterns, D.R.Y., S.O.L.I.D, redundant code, code smell,...) from senior engineers (via the internet or in real life) as you work on your projects 2. Make sure you're pushing yourself with your projects. For example, have you ever dealt with a yaml file using Github actions? Have you ever designed a database? Have you ever implemented OAuth? Have you ever implemented optimistic updates? By pushing yourself, you avoid making another regurgitated C.R.U.D. app! 3. I would also read articles and concepts you're not familiar with to get a high level overview around the systems (i.e. network protocols, DNS,...) that drive applications What say you?
To view or add a comment, sign in
-
"Can you just fix this one line of code?" 😅 If only it were that simple. What seems like "one quick fix" is often tied to a web of dependencies, outdated scripts, and backend chaos. We’ve seen it all – from legacy code holding systems hostage to patchwork fixes that just delay the real problem. The truth is, a strong backend needs more than bandaids – it needs a full-on rebuild sometimes. 🔧 Got a backend issue that won’t stay fixed? Let’s tackle it the right way. DM us and let’s clean up the chaos. 🚀 #BackendDevelopment #WebDevelopment #EfficientCoding #SimpleFixMyth #WebsiteOptimization #TechSolutions
To view or add a comment, sign in
-
KISS. Ab/using Swift advanced features is not synonym of increasing readability/code maintenance. If you don't really need them (performance, specific architecture pattern needs) you might not need to use those features and it might be worthy to sacrifice some extra lines of code in favor of better readability: - Force unwrapping - Property Wrappers - Abuse of Extensions .... You will find a non exaustive and objective list of language syntax and features that you might not need to (ab)use in order to implement your software. https://lnkd.in/e3wzsbz5
To view or add a comment, sign in
-
From every light, from every line of code, the improvements are much more evident. Even the crawling stage of work shines with a team that manages the technical infrastructure correctly. Today, we will discuss how important it is to organize our code properly and carry out our work processes with optimal efficiency. The interesting part is; the situation is the same in every area of life. For example, consider building a body. A regular and scheduled life means better performance. Technical infrastructure follows the same path; an organized and disciplined process results in speed and reliability. Whether managing a company or a codebase, the method is the same: Be well organized. We cannot make swift moves without laying the foundations, right? You cannot manage a company without planning; you cannot realize the plan without the infrastructure, and nothing is more critical than the infrastructure that enables us to reach our goals. The foundation of your plans is crucial, just like making a choice between Kotlin and Swift. So let's make today a day that is even better organized and filled with improvements! We will progress further together. #Management #TechnicalInfrastructure #Efficiency
To view or add a comment, sign in
-
THIS STORY IS NOT FOR FAINT HEARTED DEVELOPERS !! That was a night of no moon. 2 developers were assigned a task. "I still get shivers remembering it" - said the victim. They had to go through a legacy codebase that was not maintained from a long time (20 years). They heard rumours that no one wants to go through this and the team working on it mysteriously disappeared (Laid-off 💀). "The repo looked good with a well-defined readme and local deployment steps" - said the victim. They cloned the repository in their local and tried to open that in vs-code. "The screen was all RED and filled with errors. No compiler was supporting this" - said the victim They tried to set up this locally. They needed to downgrade a lot of system packages. They then started the command to run the local deployment while suddenly the guy who was presenting the screen and running the script disappeared from the meeting. "I was sweating like crazy!! I tried to message my friend over Slack but he seemed offline !! I tried calling him over Gmeet again but no answer. I called his cellphone directly. He told me that his MAC is was frozen and he was unable to restart it. We can continue over the phone-call he said" - the victim . They continued to go through this codebase over the call when suddenly ......... STAY TUNED FOR PART-2 💀 PS: This story is based on real incidents. Repost with your network if you want to give your fellow developers a Sleepless Night 😈 !!
To view or add a comment, sign in
-
MobX-State-Tree is shipping a new major version (that's right - two majors in one year!) But mostly this one is just due to strict semantic versioning. The upgrade path is pretty short. I would bet about 95% of our users won't even notice. Still, we do our best to keep the library stable, and a lot of times it means being aggressive with major versions. In v7, we are getting stricter about the equality of processed snapshots. In the past, we ran equality based on "does this snapshot ever end up valid?", but now we will only check for equality of a valid snapshot coming *in*, or a valid instance. This is exciting stuff, I know. If you also want to split hairs about what it means for some JSON-looking stuff to "be" other JSON-looking stuff, come contribute. I promise we are friendly, even if the subject matter is sometimes brutally nuanced. Release notes for the preview of v7 are here: https://lnkd.in/g8Mgmg5W
To view or add a comment, sign in
SVP of Delivery
4moLGTM (approved)