Lucky me I had to chance to attend another presentation training provided by Florian Mück.
Of course in the beginning I was very sceptic because I already attended 3 other trainings before and I was told that this one is special. Yeah of course I was told the same about the other 3 trainings 😉
And yes, it was special. Definitly that was the hardest training I ever attended and on the same hand the best one. So why?
I would say that this is just half a presentation training. The other half is about getting to know yourself, jump out of comfort zone and also from the team building persepective it was really intense. I think it is very uncommon for a training that you talk about feelings, your family, people where crying, yelling, singing and much more. We really had a lot of fun and I think it changed really the way of doing presentations in the future.
And of course we also learned some very good tools to structure any speech or presentation from a business presentation to a speech at a wedding. In the end it is the same.
And also this is not a big surprise (Just a rough overview):
- Short introduction, use a quote for example
- 3 arguments in a climax
- Summarise and state a clear call to action
- Come back to beginning
Also for me it was totally funny that in fact more than 95% of all business presentations are no presentations but lectures: So we write everything on the slides instead of make them easy and tell the people instead of putting them to sleep.
So I really encourage you either to do this training or at least get the book of Florian. And no, I am not getting paid for the advertising 😉 But it was really good!
GD Star Rating
As promised some thoughts about managment. For those that do not know currently I am working as a „Head of Engineering“ which means 25 engineers and 2 Scrum Masters are my direct reports.
One of the main challenges I am facing is how to get at least a glympse about how people are feeling and what they do to be able to provide feedback and advice at the right moment. On the other hand people want to know what I am doing because also this is mostly not obvious to the people. And this os not their fault because beside people managment I have some projects and also I am quite often on the road either becuase of the projects or also th show face in one of the other locations.
Basically the question is how to take care about a certain level of interaction and providing information to the people. Yes, regular one-to-ones are one option and I do it. But to be honest I am not capable of do that more often than once a month with each of them.
People als tend not to come and ask their „boss“: What are you doing? Or stating: Mhhh, today I feel not well today.
So, it might sound funny, but I really try to spend half an hour a day, walking around the office and the kitchen, drinking a coffee with the guys or just approaching them at their desk talking to them about projects or even work unrelated stuff. One might think that really distrubs them and distracts them from their current work but you get a really good feeling if they are in the tunnel or have some minutes for chat. From my point of view it is even the other way around so they really appreciate me, coming around and being interested in what they are doing. And this is not pretending because I am interested. Sometimes it is even enough to stick your head in the office and have a look around and you feel if something is going on or everything is okay.
For me this is really super important and this half an hour has imho one of the best ROIs of all management tools that I know so far.
GD Star Rating
Often I ask myself what is the reason to write articles in my blog. Is it useful? Does somebody read the stuff? Or is this just a waste of time?
Perhaps the last question is easy to answer. I would not do it if it would be useless. But why do I do it?
This is much harder to answer. According to the stats some people are reading my blog. So do you 😉 At the moment approx. 70 per week. So thanks for that. But back to the topic…
Basically for me the main reason is that I use this blog as a kind of notepad for stuff I did. It is quite cool to browse back in history and see what I have blogged about. It started as a blog to tell about my holidays to Australia and then evolved to something completly different: A blog about coding and other tech related topics. Kind of cool for me.
So what will this blog look like in the future? I don’t know but for sure I will continue to blog. Quite likely there is the idea to switch a bit more into the direction of IT management and organisation topics what fits to my current role as a Head of Software Engineering. But still there will be some more tech topics, too.
So stay tuned and I feel free to share and comment my articles.
GD Star Rating
I kickstarted nearly 18 months ago The Dash from Bragi.
So what I can say so far after 2 weeks of testing:
- The fit is excellent
- Step no one is updating the software
- Microphone quality is really poor
- Bluetooth range is very limited
To summarise it is really a nice gadget if you want to listen to music while on a bike or running but doing phone calls is really a mess for the guy on the other end of the line.
What I really miss is an integration into third party fitness apps. But seems to be more like a general problem in the industry that everyone does his own hardware bundled with his own app. Hope that changes in the future.
But definitely this is the right direction of a device and I hope that more stuff likes this comes to the market.
I’ll keep you updated if I have more insights on The Dash.
GD Star Rating
I think that the question what the best approach of developing software is nearly as old as software development itself is. And additionally it can not be answered because in my opinion it is totally dependent on the environment. That means if you are working in an agency on projects or in an enterprise company on products, which language and tools you are using, how mature you and your team are, …
So for the last few years test driven development seems to be the rising star in IT industry especially when you would like to have good quality. But for me it is kind of curious because it seems to me that if you have a look in the software in the market there are two kinds of software: Well tested and successful from a business point of view. Okay, this might be really black and white thinking but to be honest I have never seen a successful enterprise software that has 100% test coverage with automated tests. But of course everyone in the industry with a technical background strives for TDD. I would rather say that most of the software I have seen is mainly tested manually. Imho the reason for this that mostly I have seen some legacy software that is in the market for 3 or more years.
I think that if you start something new that a TDD approach gives you plenty of advantages, e.g. you can implement software against a specification. This comes especially handy for ETL or REST services in my opinion. But I do not think that there is really a good KPI what good quality of a software means especially stuff like Code Coverage really are the wrong approach. Additionally testing is expensive: From my point of view if you really go test driven and also write tests in all levels of the test pyramid it is easy to spent 60% of the total effort in testing. Yes this pays back. But this takes time and also might not pay back if for example you do an experiment and decide to remove a feature because it is not successful.So I think that a good team really knows best what to test and what not and if TDD makes sense for them. And especially when to do it, in the proof of concept or later.
But for me the main question is how to get to a certain level of tests and to convince people of the advantages of tests. And also if you follow my approach to do an experiment with not so good tested code and later on decide that the feature stays live the question is how to improve quality and amount of tests?
I see only one way to approach that and that also might be a good way to improve legacy software: TDBF – test driven bug fixing. That means as soon as there is a bug the first task is not to fix the bug but to be able to reproduce it in an automated way. And this should be done ideally on the developers machine. I think the advantages are clear. On the one hand the developer is able to determine if his fix works already early in the development process, root cause analysis becomes much easier and additionally the bug will not appear a second time if that test is run automatically e.g. after each merge. It sounds easy but often different environments behave completely different and writing good tests is a hard task. But definitely for me that is the thing to do to be able to maintain software and also to improve the skills of your engineers. And of course this is much more pragmatic than just saying „Now we do TDD“. Lets hope that usefull and pragmatic TDD evolves out of TDBF.
Please feel free to share your thoughts and have a nice week!
GD Star Rating