Einar Høst
Advisor at NAV
Oslo, Norway
Actions
Einar W. Høst works at the Norwegian Labour and Welfare Administration. He enjoys collaborative modelling, API design and computer programming. Over the past twelve years, he has done talks on a variety of topics, including hypermedia, resiliency, recursive art and lambda calculus. He has a PhD in Computer Science from the University of Oslo.
Area of Expertise
Topics
Death of a Craftsman: A software developer identity crisis
What does it mean to be a good software developer? What story can I tell myself that gives me direction and confidence that I am doing a good job? That provides the psychological safety that we all need as humans to function well and be happy? The narrative offered by the software craftsman metaphor is one such story - by far the most prevalent one in today's industry - but could there be others? What are the implications of the craftsman narrative? Does it have any short-comings or things that it fails to mention? Could it be misleading or even harmful? And most importantly: if I don't feel at home in the craftsmanship narrative, am I still allowed to think of myself as a good developer? What will my peers think of me? Is there life beyond craftsmanship? This is the story of a software developer identity crisis: of feeling increasingly estranged from the craftsmanship narrative and finding a new identity and sense of worth outside that tale.
The Socio-Technical Developer
Software systems are socio-technical systems: software products are intertwined with the organizations that build them. Organizational forces shape the software, which in turn shapes the organization, locking both into structures and patterns that can be difficult to change. This reality is what we need to engage with if we want to have impact as software developers, if we want our ideas to count, if we want to influence the culture we work in and shape the software being built. It's not enough to be tech-proficient. We must be able to communicate clearly and honestly, build trust and collaborate effectively, gain support for our ideas, understand and empathize with the concerns and priorities of others, negotiate fairly, give and take, choose which battles to fight and which to leave alone. But that's easy to say - how do we do it in practice?
Modelling vs Reality
To make sense of the world, we rely on our brains' capability to form fictions that we call "categories" of things and experiences. This capability is both automatic and hidden: we can't avoid doing it, yet we don't know exactly how we do it. We know that differences and similarities play a role, but how? When we try to be more deliberate about the process, for instance because we want to write software based on our categories, we call it modelling. In the process, we tend to replace our intuitive but ill-defined common-sense categories with more precise technical categories. But precision comes at a cost. In this talk, we'll look at different perspectives on categorization, see that nothing remains the same for long, and that edge cases are just regular cases that got unlucky.
Beyond the terrarium?
There is a mismatch between our ideals for digital product development and the reality of it. We speak of bridging the gap between business and IT, taking a seat at the table, direct customer involvement, self-organizing teams having the means, skills and mandate to own business outcomes. This is the ideal of the stories told on podcasts and in best-selling books. But the reality is this: Software development teams live inside a protective terrarium, sheltered from the chaotic, toxic environment of the rest of the business. Teams communicate with the environment through the means of a messenger, who bridges the world of business and development, translating needs and concerns. The business tries to control and optimize the conditions inside the terrarium, avoiding too much and too little of anything (causes laziness and demotivation, respectively), asking if the busy silkworms are feeling safe and thriving, if they are suffering from cognitive overload, all the while applying a mild pressure to produce, perhaps a little faster, a little more this time, this sprint. The levers to control the conditions inside the terrarium reside on the outside, which means that the teams can only pull them indirectly, by sending messages via the messenger. Then, the team must wait for divine intervention from a powerful being living in the harsh environment outside the terrarium. Perhaps their prayers will be answered, if not now, then soon? Eventually? This sounds pretty bad, but this model has both strengths and weaknesses. There are obviously reasons why this model has become so prevalent. What forces and constraints have produced this model? Are we still bound by them? Is it the best we can do? What does that mean for the stories we tell? Should we tell different stories instead? Or should we try to change reality? What would it take for us to break down the terrarium and expose our development teams to the full extent of reality? Are we willing to do that? Is it worth the cost?
Please note that Sessionize is not responsible for the accuracy or validity of the data provided by speakers. If you suspect this profile to be fake or spam, please let us know.
Jump to top