When we think of greatness in the world of sports, one name that immediately pops in my mind is Michael Jordan. Widely regarded as the greatest basketball player of all time, Jordan’s approach to his craft is legendary. While the world of software engineering might seem miles apart from the basketball court, there are valuable lessons we as software engineers can learn from the Michael Jordan approach and apply them to our work as software engineers.

Within software engineering, innovation is the name of the game. Like I discussed in my previous blog post, we are continually searching for ways to optimize work, boost productivity, and deliver value to users more efficiently. As we explore prompt engineering in the context of software development, a crucial question arises: Is it a complementary tool enhancing our software engineering arsenal, or does it pose a fundamental challenge to traditional software engineering practices?

In our wonderful profession of software engineering, the demand for predictable high-performing teams is growing. To bridge this gap, organizations are constantly trying new methodologies and practices. One such practice that has gained momentum is Developer Productivity Engineering. In this blog, I’ll dive into the world of Developer Productivity Engineering, exploring its principles and how it can empower teams.

Michael Jordan once said, "Talent wins games, but teamwork and intelligence win championships."

This quote perfectly illustrates the importance of team culture in building high-performance software development teams that can work together effectively to achieve a common goal. In software engineering, this means understanding the concept of team topologies and how they can shape and support team culture.

A Software Bill of Materials (SBOM) is a broad inventory of all components, libraries, and other third-party assets used in a software application. It’s a detailed list of all the components that go into the software, much like a recipe lists the ingredients needed to prepare a dish.

Developer experience, or DX for short, describes the overall feelings and perceptions a developer has while interacting with a language, tool or technique. The easier it is for a developer to work with the language, tool or technique the higher their sense of DX is. In this blog, I will briefly touch on DX but will also focus on experience in a broader meaning within software engineering.

About a month ago I was co-host of the online conference Inclusive Design 24. This free 24 hour online conference focuses on inclusive design and shares knowledge and ideas from analogue to digital.

As a software engineer with a focus on architecture, my view on software inclusivity was very much focused on usability by people with different disabilities. These are very important considerations of course, but this is by no means the entire spectrum of inclusivity.

In this blog I will share my insights and thoughts on how we can take small steps in our day to day work that can make a huge impact on the inclusivity of our software.

Will Quantum Technology change the world of Software Engineering completely?

Let’s start by saying that I am no expert in the field of Quantum technology. I am just very interested in what the possible impact of this shift in technology will be in our field of Software Engineering.

If you would like to know more about the basics of Quantum technology, I highly recommend checking out the website of the QuTech Academy for further reading.

In this blog I am sharing my thoughts on how Quantum Technology can impact the world of Software engineering and hopefully inspire you to think about the possibilities that lie ahead.

In my last blog How tech culture can contribute to quality I focused on how passion and motivation builds a tech culture. This helps people develop themselves in a positive way while organisations are more successful in delivering high quality solutions. So basically everyone wins. In this post I want to dive into how we can help educate the community in a way that they understand not only what to do with certain knowledge, but also why things work in a specific way.

At JDriven our mission is to improve the quality of software engineering. This is a great and noble cause and also something that cannot be achieved in isolation. I believe this is something that the entire community should be aiming for and can be achieved with the right mindset.

But how can you stimulate and create this state of mind and environment where quality and productivity go hand in hand? First let me start by saying this is my point of view and by no means a silver bullet. Just read and take what you think is useful and leave out what’s not.

Great to be the one kicking off our yearly blog festival Blogtober! This first blog is not particularly technical, but this subject has been the most prominent thing on my mind during the last 6 months. Connection with colleagues and sharing knowledge is part of our DNA at JDriven, better yet, it is part of our vision as a company. Throughout the years we gathered lots of experience in how we share our knowledge with the community. But this was always in a world without social distancing and other connection limitations.

Nowadays we see more and more intelligence added to our applications. This can be in any form but mostly we see it in the form of predictions or some form of recognition. This added value comes at a price and requires a new way of working within our established Software Engineering practice.