Retrospectives Are Hard for This Developer - Let's Log Them Like a Diary
This post was migrated from Tistory. You can find the original here.
2024 - Q1, Q2, Q3 retrospective…
A retrospective looks back on the past to define it, and in doing so, grounds the present and the future.
I find it really hard to define the past. There’s so much to weigh, but there’s no clear right answer, and both I and the world keep changing.
So instead of a heavy retrospective, let me just jot down whatever thoughts occur to me right now, the way you’d write a diary.
Maybe once enough of these entries pile up, I’ll be able to talk about “retrospectives” more lightly.
What are my values right now?
The world isn’t perfect, so I want to push against it and make change happen.
An organization that built “the way things have always been done” isn’t necessarily an organization with high talent density.
The world also keeps changing, and there’s no limit to technological progress. Even things that brilliant people put their heads together to build eventually become legacy.
So what are the ways I can have an impact in the field of development?
- Core technology R&D that influences the industry (researchers, developers)
- Creating new value from that R&D’d technology and applying it to the world (developers, entrepreneurs)
For example,
Technology that generates photorealistic images from text was opened up. (1)
That technology was applied to design/editing software, creating new value. (2)
That new value had a huge impact on the film industry and changed the existing paradigm of filmmaking.
(1) Researchers do R&D on core technology and influence the world.
(2) Developers and entrepreneurs discover and apply new value from technology that’s been opened up.
The domain of discovering value and turning it into a viable business belongs to developers with an entrepreneurial bent.
The domain of applying value is something every developer shares.
- Note: I’m speaking from a developer’s perspective here — I’m not saying only developers discover and apply value!
Like everything else, applying value takes a lot of deliberation and experimentation.
I think the more members there are who don’t proactively engage in this process, the lower an organization’s talent density becomes.
I believe in engineering thinking.
Whether it’s approach 1 or approach 2, the most important thing is “engineering thinking.”
Conditions change with the market, goals change with conditions, development changes with goals, and what gets used changes with development.
I think engineering thinking is the ability to define the right problem amid countless contexts, learn flexibly, and confront and solve problems.
Whenever I’ve talked with developers I have a lot to learn from, or watched their interviews, talks, or presentations,
I’ve tried to catch a glimpse of their way of thinking, their approach, their insight — and by now I’ve accumulated a fair amount of that.
Sometimes I also spend a lot of time wrestling with questions like these:
“If I don’t have a track record with a particular technology, do I lose value in the market?”
“If I’m a junior building something in a place where the development culture isn’t mature yet, does that have any value?”
All I can do is believe that I can demonstrate the ability to define problems within my authority and solve them in an engineering-driven way.
I don’t think proficiency in a specific technology is inherently meaningful on its own. But,
if you dig deeply into learning A, you get closer to its underlying foundations, and your perspective broadens, letting you define and approach problems more concretely.
If B shares a similar foundation with A, then even without directly studying B, you can gain a concrete feel for it based on A,
and the deeper you go into these foundations, the more insight you can gain into all sorts of technologies, C, D, E, and so on, that share that common foundation.