In my previous blog post Prompt Engineering: Tool or Threat to Software Engineering?, I discussed what Prompt Engineering is and how it can be used to help us as software engineers. In this follow-up blog I will dive into Claude 3, the latest AI from Anthropic, and how it can impact us as software engineers.
In our day to day work we are always striving to innovate and deliver high-quality software. One technique that could help you be more successful in achieving these goals is inner source. Inner source refers to applying open source principles within an organization. It is about adopting the collaborative, transparent, and decentralized approach commonly seen in open source projects and applying it to the organization’s internal software development.
As software engineers, we are constantly looking for ways to build faster, more scalable, and more efficient systems. But we often overlook one critical aspect: sustainability. Just as in sports, where long-term success comes from balancing peak performance with endurance, sustainable software engineering is about creating systems that not only perform well today but also remain viable and efficient in the future.
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.
