A new fresh year brings new beginnings to some things but with Dev Breakfast, we're continuing on the great path with all of you. To kick off this year, we have a selection of content related to abstraction and technical debt in software projects from Senja.
Senja is a front end developer with a design background. She learned programming in high school, but didn’t get the spark of inspiration and interest in programming until in her first job after university. Senja is interested in many aspects of frontend development – currently mostly accessibility and design systems. You can read more about Senja’s thoughts on FE dev, inclusion and similarities between programming and handicrafts on her blog.
When we learn programming, we are introduced to the principle of DRY (Don’t Repeat Yourself) code, and in order to reduce repetition, we are taught to create an abstraction that works in both/several cases. This way our code is less bug-prone and efficient.
In this blog post, Sandi Metz points out that there is a point in time, when the abstraction already covers (too) many cases, and that when we would need add one more case, the abstraction has become so complicated that it is better to add a repetition, and not over-complicate things.
Continuing about abstraction, Cheng Lou, a member of the React core team, talks about the levels of abstraction of libraries, tools and frameworks. Most of the examples, like Grunt vs Gulp, are outdated in the sense that they don’t contain the newest tools/technologies, but the ideas and points are still relevant today. Also, as Cheng says, this talk doesn’t have many concrete or useful examples (because the talk’s level of abstraction is so high), but I think that this talk explains well, how and why some front end frameworks, tools, and libraries have a short but popular lifespan (they have a lower level of abstraction) and why some others have a longer lifespan, but might be more controversial (they have a higher level of abstraction, and people’s opinions differ about how to use that power that comes with abstraction).
This is a quite advanced talk, so if all of the concepts and points don’t open up to you on the first watch, don’t worry, rewatch it later and you’ll get more out of it.
This blog post is an oldie, but a goodie. In this post, Martin Fowler talks about different aspects of technical debt. He outlines two different axes - the risk level (careful/prudent vs. reckless) and the level of intention (deliberate vs. inadvertent), and talks about the different technical debts that are formed in the technical debt quadrant by these two axes.
This is a good post to read at least once a year - it reminds us that in every software project, there is some sort of technical debt, whether the team members are aware of this or not. This post also provides good vocabulary of how the debts differ - with words that business people also understand.
Streams are a handy tool to structure your application with asynchronous execution in mind. We went over the basics in our last episode. You understand a concept better if you implement it yourself. So we will build our own small streaming library in this live coding session.
"Being a developer is all about creating solutions that bring value and every team member plays a part in that. That combined with the flexibility and freedom provided by the Futurice culture really gives me the opportunity to craft my days and project practicalities to fit my needs," says fellow Futuricean Markus.
While the focus is mostly on creating technical solutions, we do have a good time working in collaborative multidisciplinary teams. You're not boxed into a certain role but instead encouraged to expand on skills to front-end development, have discussions with clients and designers on the purpose and goals of the services being built.