The meeting section is really important, I started to reject more meetings where I think I'm not needed, explaining to others why I'm not joining. This cleared so much of my calendar for deep work!
@@ArjanCodes Engineering manager here and I can guarantee that all those meetings are also a killer of my productivity. I can almost only code after hours at this point and need every minutes between meetings to take care of admin blockers, RFCs, career development for my team, reviewing dependencies, compliance, etc ... Jayme Edwards from Thriving Technologist, or Dave Farley of Continuous Delivery have great videos around becoming a SWE Manager (ML Engineering manager in my case close enough).
@@ArjanCodes Meetings get a lot of hate, but half the time the point of the meetings is getting teams together to build bonds. ArjanCodes is relatively small, so the folks on your team collaborate directly with each other all of the time. In larger companies, that feeling of shared culture and collaboration between specialties can easily get diluted. As well, the more complicated companies get, the more competing priorities there are, the more of those meetings are really just negotiations for resources between teams. That said, if you have good middle managers, they're saving you from meetings. I'm invited to a lot of meetings, but my manager is capable of handling most of them, and pulling me in only where necessary. And, in turn, as a staff technical my role includes meeting with my manager and senior leaders to have conversations that protect the time of seniors / intermediates on my team. I need to be in the room for strategic conversations, but most of the time seniors and intermediates don't. The real killers are the meetings where no one's getting value out of them.
@@benjaminbertincourt5259 Well sounds like you need to lay out more boundaries, why you need a raise, or why you need another employee. Speak up for yourself.
I wish I could convince my team to do away with daily stand ups. Especially considering my team is 6 people who are rarely ever working on the exact same project so knowing what they are doing that day is basically useless.
Sounds like my workplace. Right now it is even worse where I work. Our team is the same size as yours, but all of them - except me - work on one project, while I work on a different project with a team from another facility. To make matters worse, communication with that team (which would be relevant for me) is limited by the fact that they are seven hours behind us - so by the time they start working, I am already leaving. So most of it goes via email, and introduces a round-trip delay of a full day. But even if not joining the daily meeting was an option for me, it wouldn't do me any good, as we don't have a dedicated space to do it. It's happening in the only open space we can use for that, which happens to be right next to my desk. So even with me not participating, I would still be in the middle of it.🙄
Dunno about you guys but daily meetings are one of the reasons I feel like I am not an engineer. I feel worse then I did in high school while waiting for the teachers to start the questioning. I also love those people who need to report every little detail on what they did and make the meetings last for 1+ hour.
I really enjoy these types of videos, as they break down the process of writing software. Once you're out of beginner level coding tutorials, content like this is harder to find and more valuable. I've been out of that space for a long time and have developed my own processes, but it's still nice to see how other professionals design their workflow so that I can find improvements and new ideas.
Great video! Doing some reflection about the development team I'm working in, I've come to realize that the last part about trust is very important. We do not really have that mutual trust between each other. There is a vast difference of both experience and skill between the members, where the old developers (self-proclaimed seniors) have experience but have not updated their skill in over 5 years and the newer developers have a huge drive in learning and creating maintainable code but lack some of the domain knowledge. So, the old and new developers often clash when it comes to making decisions on how to design a "version 2" of our system. When one of the groups do not get their designed proposal put to production, the gap between the groups widen. Lately we have been narrowing the gap between the groups little by little, but occasionally an important project comes to our table and once again the gap widens. I think this is where we have our biggest challenge, just uniting all the members in the development team and following the standards that we have set for our code.
Dave Farley of @ContinuousDelivery has some interesting opinions on that. His idea is to never do pull requests, and just let anyone push their work into the main dev branch whenever they feel comfortable the task is complete. While initially shocked, I agree with his reasoning.
Great advice! I'll show this clip to my local teammates. Hopefully, they'll get the idea that following code conventions is a good thing, even if the code "works" just as well while not being consistently structured and formatted. The main issue is that we work with a codebase 20+ year old, with lots of (failed) attempts of systematization. It's only made worse by the fact that our Dutch colleagues think stuff like consistent formatting or naming is just "fancy" coding. Oh, and having names and comments in Dutch in an international team just sucks. Sorry for this own exorcization rant.
I would very much like to read through your SOP that you talk about around the 4:30 mark. This is something I am trying to establish with my team and finding a good balance between letting them work and figure it out , and what to enforce is not the black and white solution.
This is great just what I needed at the moment for my client… thank you so much for sharing such information. Can you please create a short video on status updates as well.
A heavy, review-intensive process gives a false sense of control to Management. But reviews are worth nothing when the team is building something that the end users are not satisfied with. As someone said (Dick Hamming), "it is better to solve the right problem the wrong way than the wrong problem the right way". That makes Continuous Delivery a far superior way of keeping the project on track than a heavy process. To illustrate, I recently witnessed a project that had a pretty heavy process, with lots of reviews. But the project needed a very costly re-design one year into it, because while it was required to support 1500 I/O points, it only managed to support one tenth of that. Testing on hardware proved the software to not be fit for purpose.
It would be nice to get a video on open source contribution process in python land. For example, getting your vscode to recognize the mypy and ruff settings in package config files. Using editable installs with a venv, makefiles, development protocols (ie. how do you actually start developing and running/testing code)
Actually it looks like I was not wrong with my own feelings when arguing with my bosses on the ratio between meetings vs. time on "real" work. As development engineers - regardless if working on software or other technical topics - one needs time to reflect the technical aspects und from time to time you need to be some sort of an artist to make physics or software do what you want to do it. Bosses, at least those in the company I was working for, seem to be focusing on timelines, schedules and such without excepting the fact that you should do things right the 1st time otherwise they'll come back ... BTW: Again another proof for (1) an excellent video and (2) for a very widespread approach on real world topics. Thanks a lot !!!
You say no (or very limited) 1-1 meetings so out of curiosity what’s your stance on pair/mob programming or even just collaborative sessions for brainstorming/creative endeavors
Good question! I like to do both pair programming or brainstorming sessions. These can be very valuable, as long as you define a clear goal. For brainstorming sessions, I make sure those are focused on exploring new ideas and not on taking decisions based on those ideas.
Hej Arjan, how do you deal with situations when some essential team member declined the meeting? Since you don't have many meetings, that could slow the things down a lot. Or you just don't have those single points of failure?)) On a side note, I believe our development team struggles to figure out those vague requirements and therefore as a corrective action we have those daily standups. Would love to hear your technical setup too!
Sadly, most companies (especially the ones with a larger size) and managers LOVE meetings because that's the way they show they're working and producing values... if so.
Reminds me of one of our managers who was in charge of optimizing some stuff between various locations in Europe reported in a townhall meeting how successful they were over the previous year. His metric was that in that time frame they had conducted more than 500 meetings. (insert sarcastic slow clap here)
Love the recommendations for meetings. That seems really hard to scale to larger teams or companies with lots of team interactions. How many people are in your team if you don't mind sharing?
We’re currently at 5 people. I agree, it’s harder to do this with a very large company, since management needs to be on board with it. But I’m curious to hear from folks working at larger companies whether they’re able to implement things like this. I do think it should be possible to, at least within your team or unit, organize your meetings this way, and then perhaps leave some flexibility for meetings coming from outside your team.
The meeting section is really important, I started to reject more meetings where I think I'm not needed, explaining to others why I'm not joining. This cleared so much of my calendar for deep work!
"deep work" for middle management *is* meetings 😅 that's basically all they seem to do...
For middle management, it's their reason for existence. For us developers, it's the most efficient way to completely kill our productivity 😱.
@@ArjanCodes Too true... I am laughing through tears.... haha
@@ArjanCodes Engineering manager here and I can guarantee that all those meetings are also a killer of my productivity. I can almost only code after hours at this point and need every minutes between meetings to take care of admin blockers, RFCs, career development for my team, reviewing dependencies, compliance, etc ...
Jayme Edwards from Thriving Technologist, or Dave Farley of Continuous Delivery have great videos around becoming a SWE Manager (ML Engineering manager in my case close enough).
@@ArjanCodes Meetings get a lot of hate, but half the time the point of the meetings is getting teams together to build bonds. ArjanCodes is relatively small, so the folks on your team collaborate directly with each other all of the time. In larger companies, that feeling of shared culture and collaboration between specialties can easily get diluted. As well, the more complicated companies get, the more competing priorities there are, the more of those meetings are really just negotiations for resources between teams.
That said, if you have good middle managers, they're saving you from meetings. I'm invited to a lot of meetings, but my manager is capable of handling most of them, and pulling me in only where necessary. And, in turn, as a staff technical my role includes meeting with my manager and senior leaders to have conversations that protect the time of seniors / intermediates on my team. I need to be in the room for strategic conversations, but most of the time seniors and intermediates don't.
The real killers are the meetings where no one's getting value out of them.
@@benjaminbertincourt5259 Well sounds like you need to lay out more boundaries, why you need a raise, or why you need another employee. Speak up for yourself.
THIS is the type of information I've been looking for.
I just didn't know how to ask.
Happy to hear it's helpful! 😊
I wish I could convince my team to do away with daily stand ups. Especially considering my team is 6 people who are rarely ever working on the exact same project so knowing what they are doing that day is basically useless.
Sounds like my workplace. Right now it is even worse where I work. Our team is the same size as yours, but all of them - except me - work on one project, while I work on a different project with a team from another facility. To make matters worse, communication with that team (which would be relevant for me) is limited by the fact that they are seven hours behind us - so by the time they start working, I am already leaving. So most of it goes via email, and introduces a round-trip delay of a full day.
But even if not joining the daily meeting was an option for me, it wouldn't do me any good, as we don't have a dedicated space to do it. It's happening in the only open space we can use for that, which happens to be right next to my desk. So even with me not participating, I would still be in the middle of it.🙄
It is more about your manager than the team. It is a way to assert control and nothing else.
Dunno about you guys but daily meetings are one of the reasons I feel like I am not an engineer. I feel worse then I did in high school while waiting for the teachers to start the questioning. I also love those people who need to report every little detail on what they did and make the meetings last for 1+ hour.
I really enjoy these types of videos, as they break down the process of writing software. Once you're out of beginner level coding tutorials, content like this is harder to find and more valuable. I've been out of that space for a long time and have developed my own processes, but it's still nice to see how other professionals design their workflow so that I can find improvements and new ideas.
Glad it was helpful!
Great video!
Doing some reflection about the development team I'm working in, I've come to realize that the last part about trust is very important.
We do not really have that mutual trust between each other. There is a vast difference of both experience and skill between the members, where the old developers (self-proclaimed seniors) have experience but have not updated their skill in over 5 years and the newer developers have a huge drive in learning and creating maintainable code but lack some of the domain knowledge. So, the old and new developers often clash when it comes to making decisions on how to design a "version 2" of our system. When one of the groups do not get their designed proposal put to production, the gap between the groups widen.
Lately we have been narrowing the gap between the groups little by little, but occasionally an important project comes to our table and once again the gap widens. I think this is where we have our biggest challenge, just uniting all the members in the development team and following the standards that we have set for our code.
Would love to see your approach to managing pull requests and also an overview on automating accounting
Dave Farley of @ContinuousDelivery has some interesting opinions on that. His idea is to never do pull requests, and just let anyone push their work into the main dev branch whenever they feel comfortable the task is complete. While initially shocked, I agree with his reasoning.
Great advice! I'll show this clip to my local teammates. Hopefully, they'll get the idea that following code conventions is a good thing, even if the code "works" just as well while not being consistently structured and formatted.
The main issue is that we work with a codebase 20+ year old, with lots of (failed) attempts of systematization. It's only made worse by the fact that our Dutch colleagues think stuff like consistent formatting or naming is just "fancy" coding. Oh, and having names and comments in Dutch in an international team just sucks. Sorry for this own exorcization rant.
I would very much like to read through your SOP that you talk about around the 4:30 mark. This is something I am trying to establish with my team and finding a good balance between letting them work and figure it out , and what to enforce is not the black and white solution.
We want to clean it up a bit, but then we'll publish it so you can use it as a starting point.
The technical video aspects would be amazing. Great work!
I would like to hear more technical descriptions of the coding process, as suggested around 4:15 in the video. Thanks!
I second this!
This is great just what I needed at the moment for my client… thank you so much for sharing such information.
Can you please create a short video on status updates as well.
A heavy, review-intensive process gives a false sense of control to Management. But reviews are worth nothing when the team is building something that the end users are not satisfied with. As someone said (Dick Hamming), "it is better to solve the right problem the wrong way than the wrong problem the right way". That makes Continuous Delivery a far superior way of keeping the project on track than a heavy process.
To illustrate, I recently witnessed a project that had a pretty heavy process, with lots of reviews. But the project needed a very costly re-design one year into it, because while it was required to support 1500 I/O points, it only managed to support one tenth of that. Testing on hardware proved the software to not be fit for purpose.
Nice that you talk about that topic!
Glad you liked it!
It would be nice to get a video on open source contribution process in python land. For example, getting your vscode to recognize the mypy and ruff settings in package config files. Using editable installs with a venv, makefiles, development protocols (ie. how do you actually start developing and running/testing code)
why not have wrapper around git push that runs ruff locally prior to doing git push?
Actually it looks like I was not wrong with my own feelings when arguing with my bosses on the ratio between meetings vs. time on "real" work. As development engineers - regardless if working on software or other technical topics - one needs time to reflect the technical aspects und from time to time you need to be some sort of an artist to make physics or software do what you want to do it. Bosses, at least those in the company I was working for, seem to be focusing on timelines, schedules and such without excepting the fact that you should do things right the 1st time otherwise they'll come back ...
BTW: Again another proof for (1) an excellent video and (2) for a very widespread approach on real world topics. Thanks a lot !!!
You say no (or very limited) 1-1 meetings so out of curiosity what’s your stance on pair/mob programming or even just collaborative sessions for brainstorming/creative endeavors
Good question! I like to do both pair programming or brainstorming sessions. These can be very valuable, as long as you define a clear goal. For brainstorming sessions, I make sure those are focused on exploring new ideas and not on taking decisions based on those ideas.
Hej Arjan, how do you deal with situations when some essential team member declined the meeting? Since you don't have many meetings, that could slow the things down a lot. Or you just don't have those single points of failure?))
On a side note, I believe our development team struggles to figure out those vague requirements and therefore as a corrective action we have those daily standups.
Would love to hear your technical setup too!
Rust mentioned! 😍
😎💪
Sadly, most companies (especially the ones with a larger size) and managers LOVE meetings because that's the way they show they're working and producing values... if so.
Reminds me of one of our managers who was in charge of optimizing some stuff between various locations in Europe reported in a townhall meeting how successful they were over the previous year. His metric was that in that time frame they had conducted more than 500 meetings. (insert sarcastic slow clap here)
Love the recommendations for meetings. That seems really hard to scale to larger teams or companies with lots of team interactions. How many people are in your team if you don't mind sharing?
We’re currently at 5 people. I agree, it’s harder to do this with a very large company, since management needs to be on board with it. But I’m curious to hear from folks working at larger companies whether they’re able to implement things like this. I do think it should be possible to, at least within your team or unit, organize your meetings this way, and then perhaps leave some flexibility for meetings coming from outside your team.
What tool do you use in the Kanban section?
I think he mentionned Notion
Correct, that’s Notion.
did you change the camera recently? which one?
you look handsome... (unrelated to camera change though :))
gggggggg greeat