DRY Problems
Last week I read a bunch of interesting posts I want to share with you. Let’s dive right in!
#Reuse & Coupling
After her great post about correctness, this week’s highlights include another one by Jessica Kerr. She elaborates how reusing code across multiple teams or projects introduces coupling and can lead to negative consequences.
📃 Why libraries can create problems Reuse by Jessica Kerr
#Tips to prevent over-engineering
My next recommendation was mentioned in Jessica’s post, since it also has some points about how reuse can create problems.
The post includes the following image, which reminds me of over-engineered CSS. One could replace the label “Action” with “Class” and “Logic” with “Mixins/Base Classes” to highlight how people avoid repeating themselves in CSS. Remember that DRY creates coupling.
📃 Subhas Dandapani post about: Modern Software Over-Engineering Mistakes
#10x Programmers
This is an interesting post, which takes the term “10x programmer” seriously. The author lists different skills of these mythical programmers that in combination can result in a much faster and bigger output.
My personal opinion is that these programmers exist. The factor might be too little or too big, depending on the task and with whom they are compared. I call them senior programmers.
Make the thought experiment compare the best programmer you know with someone just starting to program in an imaginary task. The time to completion and end result is likely to differ a lot, possibly by a factor of 10 or even higher.
My favourite part of this post is about simplicity, because I’ve seen multiple times how it makes a huge difference in a team’s velocity.
An initial design error, in the wrong hands, will not generate a re-design of the same system, but will lead to the design of another complex solution in order to cope with the initial error.
Salvatore Sanfilippo
📃 Salvatore Sanfilippo post about: The mythical 10x programmer
#Elm is not perfect
I think, that Elm is the best environment to build web applications today. Nonetheless it is not perfect. Nothing is, because everything is a choice of different tradeoffs. For now Evan has made the right choices in my opinion and I am excited for the improvements he’ll make to the language.
Noah Hall is very active in the Elm community and was a colleague of Evan at NoRedInk. He recently published two interesting posts about some of problems he face when writing Elm.
I remember meeting Noah at a meetup here in London and I asked him, what he does not like about the langzage. Back then he couldn’t answer the question. I believe these posts are not about things he doesn’t like though. It’s more about giving constructive feedback by pointing out problems, that exist, because of the way the language/some API is designed. He also points out possible solutions and workarounds.
Posts like this are very valuable for people evaluating Elm as a technology.
📃 Noah Hall about: JSON decoding in Elm is still difficult
Why type classes aren’t important in Elm yet
#Beautiful Case Study
technologyreview.com is my favourite website design for a while now. Nice big typography, strong colors and great content.
(Improbable is on their list of 50 Smartest Companies 2016)
Apparently this design was done by Upstatement, a creative studio based in Boston. I recently stumbled upon their case study for the project and it is gorgeous, too. Reminds me of those great case studies by Teehan+Lax.
🎨 Take a look how they made the animated posters too: Upstatement’s MIT Technology Review Case Study
I hope these links sparked some ideas in your head as they did for me. I’m thinking about writing another text-focused post for next week’s edition, since I have some thoughts in my head about agency/product work. I won’t promise anything though, since they are still very vague.
I wish you a great week! 💪
PS: The regular reader might have noticed, that my link styles have changed. Yes they did! I hope you like them more than GitHubs new link colours. 😉