Posts tagged with philosophy
In a new post David Hemphill argues that you sure can (re)build something that already exists. I fully agree.
Some folks ask this rhetorically, implying there's no good reason when something similar already exists. They ask this question with a smug grin and think they've got you.
Read more [davidhemphill.com]
Some wise words by Mathias Verraes
We must remember to think of a design pattern as “a problem in a context with a reusable solution”, not merely “a reusable solution”. If two patterns have identical solutions, we should not think of them as the same pattern.
Read more [verraes.net]
Join thousands of developers
Every two weeks, I share practical tips, tutorials, and behind-the-scenes insights from maintaining 300+ open source packages.
No spam. Unsubscribe anytime. You can also follow me on X.
A nice insight by Basecamp engineer Jonas Downey.
Whatever ownership you have over an individual contribution is immediately forfeited the moment you commit the code. At that moment, the work becomes part of the ever-evolving organism that comprises a software system.
Read more [m.signalvnoise.com]
React lead dev Dan Abramov makes the case for naming your ideas and projects.
The problem it’s solving might be so ingrained that we don’t even notice it. It’s the elephant in the room. And we can’t discuss what we never named.
Read more [overreacted.io]
Ross Tuck makes the case that not all code is equal.
Most teams follow the Broken Window Theory, fearing even a single tradeoff starts the slide down a slippery slope. This can reduce discussion (read: dissension) in the short term but leads to arbitrary compliance or worse. ... Deciding on a level of quality isn’t like deciding on a coding standard, you can’t have an off-the-shelf-always-okay answer. Quality is the place to have nuanced discussions.
Read more [rosstuck.com]
This talk given Ross Tuck at the exec(ut) conference is one of the best talks I ever saw. I highly recommend to sit comfortably and give it your full attention.
In a new post on his blog, my favorite stalwart of the industry Frederick Vanbrabant, gives a explanation on why some projects turn into a big mess and how you can avoid it.
I truly believe that the broken window theory can be applied to software projects. In my personal experiences I’ve rarely seen a project start out as a total mess. If it ended up as a mess, it was gradually. I also believe that this is not necessary the fault of developers working on the project, think of it more as frogs in a pot with gradually increased temperature of water. One morning you just wake up and take a look at the project and realise that it has gotten really messy.
http://frederickvanbrabant.com/2017/06/12/broken-windows-theory.html
Like at most previous editions, DHH delivered a keynote at RailsConf 2017. This year he spoke on the importance of belong to a group, programmer values, and belief systems. I love being in the Laravel community, but one thing that annoys me sometimes is the "us" vs "them" mentality you feel here and there. What I find great about DHH's talk is that is a positive approach to the values of Ruby community. He doesn't say that the other communities are bad, or lesser then them.
Anyways, go watch this keynote, it's great.
DHH explains that there's nothing wrong with a bit a magic.
It’s always better to be explicit! That’s pretty much a programming truism. Rarely directly challenged, lest one betray the foundational tenors of Proper Programming. But challenge it we should, and head on.
https://m.signalvnoise.com/programming-with-a-love-of-the-implicit-66629bb81ee7
Jeff Geerling, currently working as a technical architect at Aquina, wrote a good post on when and why he closes PRs to the packages he's maintaining. This paragraph resonated with me.
I don't cater to everyone. I usually cater to myself. And for 98% of my OSS projects, I'm actually using them, live, in production (often for dozens or hundreds of projects). So I'm generally happy with them as they are. I will not add something that increases my maintenance burden unless it's very compelling functionality or an obvious bugfix. I can't maintain a system I don't fully understand, so I like keeping things lighter and cutting off edge cases rather than adding technical debt I don't have time to pay off.
http://www.jeffgeerling.com/blog/2016/why-i-close-prs-oss-project-maintainer-notes
An excellent talk by Eryn O’Neil that underlines the fact that the code we write should be as humane, warm, emphatic and thoughtful as we ourselves need to be in real-life.
Andreas Creten explains his view on wether you should always try to write perfect code. Spoiler: no.
The engineers want to write perfect code using the latest techniques, make sure that the code is well documented so they can fully understand how everything works and that it has tests so they can easily update things later. Product owners on the other hand just want things to be done, fast and cheap, so they can ship new features or convince new clients. How can you make these conflicting views work together?
https://medium.com/we-are-madewithlove/does-code-need-to-be-perfect-a53f36ad7163
I love those conversational posts written by Uncle Bob. This time he responds to an article by Luciano Mammino who is saying goodbye to OO programming. Uncle Bob's conclusion:
We need to choose a language, or two, or three. A small set of simple frameworks. Build up our tools. Solidify our processes. And become a goddam profession.
Amen to that! Read the entire article on the Cleancoder blog.
Most outlets of technical information (whether high profile developers, companies, etc…) focus on architectural patterns and there’s never any talk about organizational patterns. In other words, does the architectural pattern that you choose fit your organizational pattern?http://eli4d.com/2015/12/23/fullstack-radio-podcast-episode-with-dhh-shaping-your-technical-patterns-based-on-your-organizational-patterns/