Very opinionated slidesets and presentation.
Slides were made for presenting ideas in context of current project and company, which is not generic enough to make them something you should think in terms of "right" or "wrong". Some ideas might apply to other contexts also, but you should manage to estimate tradeoffs by yourself to decide if they have value to you.
Not all of slidesets are finished. They might still be worth browsing, for which reason they are shared.
Why bother to think, iterate your ideas, ask constantly "why?". Isn't it enough to just write next line of code? Read Uwe Friedrichsen, Essential Architectural Thinking
I have programmed for a long time. It's still fun and I enjoy it.
Currently I'm in mid way to understand that the whole power of what I have done is not a skill of decoding commands to computer. It's all on persons, interaction, within team, with customers. I'm curious to understand more of it.
To understand where I am and why I am I tend to think organisations and environments where I have worked. All of those environments have influenced me, but currently I'm more aware about what they do to me. I am one of the global few persons who doesn't need to work for money, but I still see how the Way We Think about Work is Broken - Barry Schwartz
"(..) what Adam Smith was telling us there is that the very shape of the institution, within which people work, creates people who are fitted to the demands of that institution, and deprives people of the opportunity to derive the kinds of satisfactions from their work that we take for granted" - Barry Schwartz
I'm motivated by search of understanding boundaries and possibilities, what I can professionally offer to others and what I need. Curiousity has lead me to wonder how to activate the ‘seeking system’ of your brain - Dan Cable
"what's interesting is if you start with humanity, and you start with "you're a person, there are probably things about you that are unique, that we should know about". Why don't we start by socializing some of the ways that were unique, and that we add value to the team. And I think by humanizing that relationship, it's so simple, but it actually stands out as being rare." - Dan Cable
Mindsets are important. Developing Growth mindset can be learned. Enjoy the power of 'yet' with Zoe and Elmo from Sesame Street
"Making mistakes and coming up with solutions to solve your problems is exercise for your brain. Whoa! It's brainercize! Right! When you believe you can do it and you keep trying, that's when your brain is growing and you're learning new things." - Sesame Street
"agile, adjective - able to move quickly and easily" - Oxford Dictionary
Agile isn't "done" by following Scrum. Scrum is just a tool to help you to communicate. If you don't understand why you are doing Scrum, maybe you should not do it. Or: you can try to understand it better.
This is my take on Scrum basics. It's written for non-professional purpose, and is partially in German, but it might be useful for you also.
But if you want to learn, then, where to start? See A S C R U M B O O K, it's free to browse online.
All golden? No, see "Agile Methods The Good, the Hype and the Ugly," Bertrand Meyer or read his book.
But you might also want to see Scrum Guide as it's "the" official source of Scrum.
Whatever you do; remember, many projects fail. Regardless of methodology. Is Agile better? Is Scrum better? Maybe, but it's not a a secure way to success.
Pay close attention to feeling of people working on topic, if they believe in what they do, if they respect each other, if they are happy. It's not Scrum that does the work, it's your team, or: you and me and whoever we are working with. It's not sticking to rules, it's understanding why we are doing what we are doing.
Themes
- Your team is not performing? Maybe it's not team at all.
- Where did happy go? and where comes motivation.
- Trust is the key. But how to build it?
- It's not just bricks. We build cathedrals.
- Happiness is on your relationships to others.
That's not technical stuff, but how to enable people to work together better. Sure it's also about money and profitabilty, as Teresa Amabile - The Progress Principle - states that "dissatisfaction leads to slower revenue growth and lower profitability, in other words, employee engagement drives the bottom line".
Important to you is also Does your job match your personality?, which Jordan Peterson comments “If you’re a creative person who is open to trying new things — openness being one of the Big Five personality traits — you’re more likely to succeed at jobs that require novel solutions over efficient ones. On the other hand, if you’re conscientious — another Big Five personality trait — you’re likely to be better off in a management or administrative position.”
There's good reason to solve conflict between software developers and managers, or said otherwise: between creative - open - and administrative - conscientious - persons / roles..
As Jordan Peterson observes “So there’s this terrible tension in organizations, and I think what generally happens is all the creative people are there at the beginning. They get chased out until you have nothing but managers and administrators. Then the environment shifts, then the company dies. And so the way that capitalism solves the problem of the tension between the creative types and the managerial types is it just lets companies die. Now you might think, “Well I don’t want my company to die.” It’s like okay then, you need to understand the difference between these two kinds of people — which you probably won’t and you probably won’t admit to even if you knew. And then you have to figure out how to get the balance right. And so that’s extraordinarily complicated.”
You need backend for mobile? Here discussion notes for my collegues.
This is mostly sales for Flutter. It's partly outdated, partly still valid.
Flutter and Dart form ecosystem which looks to me first really promising way to build hybrid mobile apps. Dart is flexible, easy to learn and develops constantly.It's modern, null safe and has good tooling. Flutter is starting to be mature, and migrations between versions are not too painful. It is possible to develop Android and iOS apps with same codebase, and other platforms like linux, windows, osx and web are also supported.
Flutter is cool, so maybe I'll update this someday. Not it's quick snapshot from 2022.
api driven: while model driven development (DSLs) and generating code reduces errors.
code first: while it looks easy and there's fancy examples at stack overflow.
Decision lies on your culture, usecase and legacy codebase. I have very strong opinion that modelling and sharing contracts openly would be valuable, but also that it's rare capability, which many companies might not have.
Related, and important, Uwe Friedrichsen, Getting API design right, slides and video, in German
If team is managing to embed to software everything they learn by observing how users are using system, it evolves. If team is not learning or not capable of changing their system according their growing knowledge, it suffers, and is in danger.
If gap between what is known of users needs and what software provides grows it's only a matter of time when users dissatisfaction forces them to abandon software they hoped to provide value.
Related, and important, Einar Høst, Technical debt isn't technical, slides and video
what is microservices architecture? what kind of coordination is required when local data and local computation needs to work in context of distributed systems.
or Kevlin Henney's "It Depends."
since it's not important how you learn to learn, but that you understand that it's process.
or Kevlin Henney's "Old is The New New"
This discussion is about Kotlin in backend. Solely.
Kotlin seems to be promise that comes reality so slow that Java takes over. But is it really so?
Hmm.. Think again. Null safety is important and Kotlin is safer than Java even if java is getting better. Additionally, Kotlin is more concise and expressive than Java, making it easier to read and write. Extension functions and operator overloading are also nice features which makes it easier to write clean and readable code, especially for domain specific languages.