Does your CTO, Product Manager, or Project Manager know how to treat programmers? Skip to points: 01:23 #1 Programmers Produce At Different Rates 02:27 #2 Frequent Status Doesn't Get Things Done Faster 05:05 #3 One Task Doesn't Control A Project Timeline 07:08 #4 Making Changes To Be Agile Has A Cost 09:00 #5 Programmers Deliver Faster Through Creativity 10:04 #6 Programmers Need Rest To Be Creative 11:39 #7 Programmers Can Identify Valuable Features 13:19 #8 Programmers Forced To Hit Deadlines Cut Corners 15:12 #9 Programmers Forced To Only Code Lose Focus
@@jakubrinkes1896 Agree completely. I believe some leaders do understand, they are just under pressures that feel stronger than having to account for this. I talked about overcoming that in my video about Saying NO so people will listen. When I was at a consulting agency, we discussed this a lot and decided we would never line item this work. Meaning we would assume a percentage of time needed for it and do our best to include it in estimates. But we never called it out as something that could be "removed". If we ran into an opportunity where we needed to do a significant refactoring, we spread it over each task or sprint. This requires iterative refactoring - which I think is a very valuable tool today. Refactoring in steps is possible, but tricky without a lot of experience sometimes. YMMV
I got into software engineering for the creativity & innovation, because it's both art & science, both of which I love. I've worked in some environments that value software engineers holistically and others where creativity is completely abstracted into other roles like product manager and architect. I'm motivated by impact rather than competition, which has inspired me to develop a broad skillset and embrace continuous learning. As more companies use HackerRank type assessments as their main hiring and placement metric, I got the sense development is for speed demons and creatives like me belong elsewhere, a shame considering how much value creativity can add in the fast paced field of tech. I figured my view of code as an art form rather than a factory style plug and chug process was a misconception from my liberal arts college. While I'm happy at my current position, my past experiences still make me wonder whether to stay in an overall industry that seems to value my work style less and less. Coders used to be perceived as creative geniuses in the media (overhyped imo but valued for the right things.) Then came the code monkey era. It means a lot to hear creativity is still a software engineer's most valuable asset from someone with your level and breadth of experience.
Corporations that use leetcode and hackerrank or “prequalification” companies like toptal to hire engineers get what they deserve - no insight whatsoever as to the talent of their hire. A lack of creativity is what’s causing the cost of development to rise so fast. Software development is closer to screenplay writing than engineering. You have a story you need to tell but there is amazing freedom in how to pull it off. It’s a convenient lie our industry sells to unknowing people that don’t know how to evaluate candidates that someone passing a coding interview is a good programmer. It literally just tells them they know how to study a test.
@@HealthyDev This is what I tell people when they ask me things about tech stacks or languages to learn; programming isn't about code; it's all about creative problem solving.
Yeah I probably wouldn’t do that unless you have a pretty close relationship with them. I put a couple of the points (I think it may have been #2 and #7) in the #HealthyDevTips playlist on my channel, but even a single one might be too incendiary to the wrong person. I’ll continue to do videos on communication and basic consulting influencing skills, hopefully that can help everyone pitch some of these ideas the best way possible to people that might benefit from hearing this information. A commentator on Reddit where I posted this felt my tone might be too developer-slanted to get leaders thinking in this one. Depending on the person I’d have to agree with him. For the right person, who you have a good relationship with and knows ahead of time you’re not trying to be critical but to inform, they might be able to watch this with an open mind.
I am thinking i'm going to try to take a teach by example approach, I have my scrum master certification so I will ask for an additional role as a scrum master on another team for a bit of extra leverage to fight certain things. If I can prove it is effective I may be able to lighten the load for myself and my own team.
@@ryusaikou1604 If you have the good relationship that Jayme describes, you can link then to this as an insight to see things from a developer's perspective, so they can understand why something is frustrating when it seems reasonable from where they're sitting.
Definitely a video that was needing in the industry. There's such a gap between traditional management and the modern software methodologies (ie: Scrum, DSDM, etc.) that it makes a gap in communication and expectations between software engineers and their management.
Thanks for your support. I realize just kicking a video like this over to managers verbatim probably won’t go over well. But I am always trying to help managers understand the implications of their assumptions so they make better decisions, which I know many developers also do. Hopefully people can pick one or two of these points and start a conversation about what it would look like to make the work environment support reality better.
One of my favorite projects was one where I was given a rather expansive user story by the client. I was then able to take several hours to write up a concept for the different features that would need to be built out to handle everything he wanted. He then looked that over and made some adjustments to his thinking based on things he hadn't thought about that my document brought up. I made adjustments based on his feedback and got to work. There were no deadlines other than having something the client could test out in about a month. Managers left me alone for the most part and I was able to come up with creative solutions without feeling constantly stressed, I was able to think when I needed to think and code when I had a clear direction. It allowed me to build the project out in such a way that it wasn't overly rigid and could handle change and potential expansion. One day I might write almost no code, others I wrote a ton because the previous days thinking and planning facilitated it. Every now and then I would think of something we hadn't anticipated and have to discuss it with the client. Then I would continue forward based on his input. Once I had the mvp shipped, the client had several additional things he wanted. Because I was allowed time to make a quality implementation initially, it allowed me to add on the additional requirements easily. The final product was shipped after a total of 2 months with all the bells and whistles the client asked for throughout several iterations after the initial build was complete. I actually enjoyed the work and was able to have a good work life balance throughout. After this project I was thrown into a tightly managed scrum style project with 2 week sprints and estimates they treated like commitments. There was no time for thinking, just implement, implement, implement. It didn't matter that the tech stack was almost completely unfamiliar to me, they just expected me to learn as I went while still hitting all the desired deadlines. I was more exhausted after the first 3 days on this new project than I was after 2 months of the other. In my opinion big Agile is evil and ineffective, as is scrum. I think Agile is almost solely responsible for the massive developer turnover companies experience, developers constantly looking for greener pastures where they will actually be treated like human beings rather than a resource to be "maximized" until it burns out. Programmers are forced to work with blinders on while the project manager(non technical employee usually) tries to control the reins(so they can justify their existence). It results in more work later because programmers aren't allowed, and given time to see the big picture or given the time to plan ahead, make adjustments and come up with creative solutions that will end up solving a lot of the problems before they happen that the project manager, project owner, scrum master and agile coach aren't going to know how to anticipate. The whole rigid 2 week sprint structure isn't actually very agile at all. If they just fired most of the management who are little more than parasites feeding on the developers and allowed the programmers to manage the project with the client, the client would save money and the implementation would be closer to what the client actually wanted and likely be finished as fast or faster. By turning programmers into code monkeys who are forced to work on tiny tickets every day with the hopes that all those tiny parts result in some big functional thing, they take all the enjoyment out of coding and make it an endless sprint through a dark void, with constant stress and no time to ever stop and think about where we are headed.
Hey there, thanks for sharing this difficult story. I'm sorry you went through this, and man have I been there. I hope you can find another position that lets you do great work and not be micromanaged. Sometimes it's the honorable thing to do to stay somewhere that isn't great to pay the bills. But I hope you listen to that part of you that says you can do better (when the time is right). Hang in there!
Nice video!! One informal conversation in front of the cofee machine can tell more about the project status than daily stand up meetings. We love telling about our new sw module features or complaining about technichal problems/bugs, not being constantly checked up.
I think these consulting tutorials are great, but what really hooked me to this channel was the sun-glassed story times, where you tell old anecdotes about past experiences, and how that gave you more insights. It very cool, because it brings a bit of spicyness and tension to what you're trying to convey. Besides, everyone loves a good story.
In the ideal world, programmers would not have to sacrifice the long-term project goals to satisfy some short-term whim of somebody who does not know what he wants. The decision makers do not understand the full extent of their own limitations. They are bombarded with the motivational quotes that sometimes are frighteningly far from reality. They have one foot in the fairytale world. People, in general, want their ears tickled so nothing will change for the better. The leaders will continue to have their fairytale visions and confrontation with the reality will continue to be a form of the blame game. Perhaps we should start educating the leaders about their own limitations? Do you think it is possible?
I think it’s possible. The major goals I have for this channel are: 1. Help programmers and managers understand each other better. 2. Provide support and solutions for people in suboptimal environments to make the best of their situation. 3. Be a place where developers and managers can support each other’s struggles. 4. Help current and future technology leaders foster a culture of safety and creativity so people have fun when they build profitable software.
To understand each other's struggles you also need to understand each other's limitations. To foster the culture of safety we need the culture of trust. Lots of things depend on each other in very complex ways.
Thanks for this video. You really summarize a lot of what has been going on at the projects I've worked all along. Sometimes I feel like I'm the negative guy that thinks about these issues at work when almost all the rest of the team don't really seem to care. The thing is that I'm not part of a project only seeking for the next paycheck; I want to make big impact in my everyday work. I think it's soul fulfilling when work is done and it's done well. Thanks again
You’re very welcome. I too love work when I’m able to make an impact. I guess over the years I’ve had to adjust my expectations of what that impact looks like and try to accept things I can’t change more. It’s an ongoing struggle - and it sounds like you’re already doing that!
Meetings have a cost. A Managers day is sectioned into (8) 1 hour Meetings. For them, this is routine. Developers day is different. It costs him more to start and stop. For instance if you set a meeting at 10am, you just busted up my whole morning. The thing I need time to do, is not getting started, because it has to be put down for the meeting. There is nothing wrong with a managers schedule, its what they do. Meetings are also needed with the team. But they should be very few, and very focused on one thing. Throw in a Project Manager, (Ahem , a Scrum Master") -and you get more meetings. I believe this is the core reason for conflict on projects and timelines. Its the single most anti pattern there is. AND nobody can predict the future.. HELLO COVID!!!
Especially number 2, management nagging "are we done yet?" like a six year old on a road-trip repeats "are we there yet" stresses the hell out of me. How the heck do they expect me to focus on complex code, while due to the same occurrence parents are deemed incapable of driving safely due to loss of concentration. The second most infuriating thing to me is management constantly pushing other non-project related tasks in-between the current project, deeming it an obligation to interrupt my actual project-related tasks in that process. Then acting like those completely unrelated tasks where part of the running project expecting no delays. How do they keep coming up with such nonsense? The third one is management micromanaging your every step, thereby slowing you progress down massively. Because you became slower they tend to increase the amount of micromanagement a bit more which in turn slows you down even more... Rinse and repeat... For me it's getting into 'the zone' that I find mentally tiring and draining, not staying inside the zone. Leave me in my 'zone' and it wouldn't be an exception that 8 hours passes without me even noticing, if I'm left uninterrupted I can keep working like that easily for an entire week. Force me out of my zone for 3-4 times on a Monday morning, and there are occasions where I find it impossible to re-enter my zone for that entire week during normal work hours, just because I know it's not worth it and I can best postpone the real work to this evening when I'm home and left uninterrupted. On working from home days I also tend to program between 7 to 10 am, followed by code cleanup between 12 and 1:30 pm. I then tend to complete my workday with 4 to 5 more hours after 5/6 pm, just because those are the hours management won't interrupt me trough phone, skype or mail and I can get some actual work done. But the real question stays the same, how the heck do you explain these issues to you manager and non dev colleagues when you already tried each polite and civil way possible without any improvement or results? I would actually argue that the current pandemic forcing us to work from home thereby improving work efficiency, actually saved our current project over here. But it's already clear that management won't see it that way, as they're already talking about returning to the office in the midst/start of the second wave.
The work from home has become a nightmare for us. We had clear boundaries between work and home before the pandemic but now texting at 11PM is totally fine. Can you believe my manager said, "Should we decide the deadlines by asking you?". That's the point I knew this situation is beyond repair. Time to cut my losses and move on.
@@sirrus3009 Just ignore the message or make sure to keep private and work numbers separated. Once you answer on such late messages you are literally doomed.
I don't know how youtube suggestion algorithm works, but all that mentioned in this video I constantly trying to explain to my current project team especially last week, and now I encountered this channel that talks about exactly the same things. The problem is now I'm afraid to even share this video with my company because it will look like that all I'm standing on is just a bunch of words from youtuber and not my own opinion. It's a shame how miserable I became :( when someone treats you like a child you suddenly became one. Anyway, thank you for your videos and experience
Same here but I think it all depends on how you transmit the message to others, so don't feel that way. In my case I'm enriching my notes about this by using this video's pacing for some ideas. Surprisingly these are ideas are in some of our minds already, so we're not alone
This is my 25th year as a developer. Almost all of what you said is like an echo! The best jobs I've had is where a team lead and manager were developers because they understand and can relate that to non technical managers. But even then, the politics kicks in and you end up working overtime for no pay. And that's the good ones! Others ignore technical debt and blame the developer for not fixing everything. Those are the ones when you feel like you're in a Dilbert cartoon!
Omg this is so true. I blame it on too much non tech people in software industry who just don't understand how the process works. It is ok for upper management to be non-tech, but guys who are directly involved in development process as well as middle management should have tech background. They should be a buffer between upper management/investors and developer teams to allow developers to be productive but at the same time know how to talk with other side and keep them satisfied. As you said in another video...there should be a focus on business value and not on features/tasks. That is the job of middle management to handle. As I noticed in most of Scrum teams there is a non-tech PO who is actually "leading" dev team. Put scrum master here as well with their bullshit and you get typical software project now days xD
Some leaders are afraid of a single or a few expert underlings having more real power or impact in the company than themselves and for this to be visible. They might try to "flatten" the terrain in various damaging ways. Dreaming of a team where every dev can easily be swapped out with another if he or her misbehaves.
I was in a similar position where devs would be bullied to produce results, and were even put up against each other to put pressure on each other to get things done. I realized at some point when pressure is put on you or anyone, it's passed on to the next person and the next etc as automatism, something you've learned as an acceptable method, causing a chain of misery and frustration. It's not acceptable at all! After realizing this I cut the chain and reflected it back at the source, because once the chain gets going it will circle back to you to bite you again, and even harder. It may take days, months or years to circle back, you may have forgotten it long before it's back on your plate. Then another manager tried to do the same but I had a better trust relationship with him. I explained the above and he understood after some soulsearching. We both quit the job and went our separate ways, found a really good place to work in. Now no one can put pressure on me except myself, it'll be my choice and no one elses. People are really good at putting pressure on themselves already, they don't need anyone else to do that. This change of attitude totally changed how I work with people and how I'm treated. Now, whenever I'm faced with such a person, I'll increasingly resist and be unpredictable and uncooperative, questioning every decision. Once they treat me with respect and are more reasonable (even if it's by accident or unauthentic) I'll immediately switch to being cooperative and be predictable, letting the person know I appreciate him or her. It'll totally surprise, even shock them. They'll fall back to the pressure and control pattern a few times thinking you are under their control, but once the positive change sets in, the atmosphere changes a lot for the better. A trust relationship is now possible to be build up. And for the person in question too. They are being pressured and maybe bullied too and are just passing it down to you. So send those shockwaves back up the command chain, it might just improve the whole company, even if it's just a little.
My favorite is expecting same time estimate with changes given at 11th hour. They really think we just sit at our desks and drink coffee. Agile development looks like formal name for leadership constantly changing directions. Turns devs into firefighters. We end up fighting the next fire(sprint). Agile is another name for Ad hoc type development. Devs churn out lots of code, but nothing is really reusable.
When I have brought up these items at the companies I've worked at, I get blank stares and push back and curt replies. "Just try your best" and "Just get productive" and "We need to track progress" But the issue is coming from them, they don't know what they want and have very little idea what it takes to get it done. I'm hoping the next position takes into reality these points.
That sounds like insecurity is a problem there, too. I see the same problem around me. Managers feel powerless, because they have no clue what their programmers are doing, sometimes even have a clue what they are ding themselves. Micromanaging gives them the feeling of being powerful and in control, even if they don't understand what you do, they can make the hierarchy clear by being the person who demand something. I don't think programmers need to be managed so much. Assistance would be much more useful. But this would flip around the hierarchy. I think, this is an even bigger fight and those not so skilled managers have a lot to loose.
This video is soo good, I'd love that some managers or CEO's would actually see that. Especially on my most recent company. One of the things to also have in mind is that if you keep the pressure up to deliver on the deadlines you will in the end lose out on the (few) next deadlines. Just because of all the points mentioned. Bad maintainable code, not using best practices and very spaghetti systems will lead that you may need to refactor it because some other features, using the system will not work with the current implementation. Just wanted to add that. Great video, I'm quite tempted to share it with some people I know could need that video for sure.
This is the key. Requirements Analysis! Managers don't understand that you need to know what you're doing before you start coding. Analysis is about describing what you want to do and describing data in detail and the relationships between data. Once, I worked on a project where my team worked for an entire month on analyzing the requirements for an internal installer application for our company's software. Management was concerned that a month had passed and we hadn't started coding. We told them that we would deliver in 4 months. They changed our time line to 2 months. Guess what? Our first solid delivery was 4 months and worked elegantly and exactly how we envisioned. We told them the truth about our estimate of months and we were right, and no -- we didn't sandbag. We still had a few minor tasks to complete but we delivered all of the core functionality when we said that we would originally, and the engineering teams and test groups loved the new installer. After doing such a great job, management put most of us on bug fixing. I recall fixing 75 bugs during that year. My manager at the time who was also my manager for the installer project said to me one day, "Bruce, I like that what you fix stays fixed."
Awesome testimony to the importance of requirements. I believe part of the reason commitments made on oversimplified work has become so common in our industry is at least partially due to the proliferation of user stories without understanding their intent. I talked about this in one of my other videos “Can User Stories Make Software Projects Late?”. I wonder if you’ve experienced some of this: ruclips.net/video/NavlPobhj7A/видео.html
@@HealthyDev Yes, "intent" is an excellent choice of a word. Intent is important in life in general. Why you do something is more important than what you do. Intent represents the why. I find that the biggest challenge in software is dealing with fragile egos. Rarely do I tell people that I graduated from MIT (Bachelor's 1987). Why? Because it creates grandiose expectations. Some ask me what is the biggest lesson that I learned at MIT. Well, I learned how to solve problems of course, but more importantly, I learned that I know very little. The experience humbled me. So, I put my ego aside and I've told my boss recently that truth does not offend me. Better designs or ideas do not offend me. They don't have to come from me. It's an opportunity to learn. I want our product to be better for all of our sakes. We can be honest about the issues and work to solve them in the light of day. Also, if a design is not necessarily the best, but is still sound, we can always refactoring it later as long as it is robust despite its limitations. I've learned to let some things go. As for the user story,, it can be a useful tool in conjunction with use cases, but they can only work well when you have a great scrum master who is skilled in the practice, and a team who is skilled in agile, but yes -- there are challenges when not applied correctly. I will listen to your video on user stories. By the way, great channel. I appreciate your stories and wisdom and will continue to listen.
Yep, it really makes so much sense to keep a developer, who's task is late, constantly interrupted and incapable of working due to that. It's really hard to imagine a more effective way to make sure the task will never get done.
This is the SINGLE BIGGEST PROBLEM I have with Scrum: the idea that I have to tell someone everything I'm working on or attempting. Don't get me wrong - a scrum can he a wonderful place to say "hey - I used all my research and backup hours for my sprint and I still don't know how to code this sprocket - I need help" so that (a) you get help and (b) managers and other devs can pick apart if there wasn't enough time, if they needed more context, etc. instead of saying "well, um, you know, we really needed that to be done" and kinda projecting this "well you're a developer so you should know the things" expectation. Yes... we SHOULD know the things. But when we do project after project after project and are expected to research and solve problems faster and faster, the learning time quietly goes out the door, my dev confidence drops and my engagement level wanes, and then the problems really begin.
Good point there. I completely agree with that. Scrum just kills your productivity because you don't have time to sit down and think about a problem for a day or two if it is a complex one. Instead you are obligated to "produce some value" till next daily.
Really glad you're doing this channel, keep it up man. I think your work is fantastic, and though only a few episodes in, I'm already feeling the need to jot down notes when you're talking. That's the sign of a good RUclipsr, with good experience, AND they're a good educator. It's not common to see all three but you obviously know you've got that already. What surprised me is hearing you easily wrap together multiple contexts whenever you describe the common workplace perils programmers would value knowing about. Off the top of my head in your culture change episode you discussed the incidences and lessons learned from the perspective of: a new hire, a proud young programmer, an underpaid line of workers, an unfit project manager, piss-poor leaders, new insecure colleges, and so on. Oh there's so much more, the debriefing, reflection, and autopsy must have occupied your spare thoughts for some time after that project ended. After summarizing the gist of the stakeholder's perspectives you offered your thoughts towards avoiding and mitigating the damage in similar situations in the future. Tossing in the various attitudes and behaviors required to stear through the situation (from your POV, the business owners, etc..) was pure lagniappe btw. I will binge watch your work over the wee… oh god none of that is what I came here to say. The cuts you do with the camera in this episode are fucking brilliant, but it's in the "it's a clever solution to a problem nobody else would ever of bothered to notice" kind of way…. I had you up on a second monitor 🙃 while I was working, and noticed you kept teleporting back and forth 🤨 to either side of the screen. 🤔 I just stared at your episode for a minute thinking I'd noticed some telltale sign of a new RUclipsr 🤭, but then it hit me,😮 it was a cinematography (dare I say 'style'?) decision, 🧐,because you were switching 🎥 camera angles every few moments 🎥 to keep the imagery active… simulating the effect of cutting to multiple cameras. 🙀 Why move the camera? You can just switch sides of the screen periodically using the magic of editing, and if you only stand in the same spots (I noticed) it doesn't look disorganized, and our brains area already accustomed recognize the that pattern of editing. It's too small of a thing where could really brag about it, you'd sound like Rick Santorum talking about his lucky sweater vest. But it personifies the software designer wavelength so much you'd of had to of known programmers (or video producers) would surely notice it. I hope you don't let anybody talk you out of those little Easter Eggs in the future, and hopefully they'll mature along with the rest of your channel for years to come. Good luck. = )
Confusing activity with productivity is a big mistake. The most important step in any project is finding out what's really required. It's only when you show people exactly what they asked for that they start to understand what they really want. The times I've failed have usually been when I've failed to define the requirements properly. It's also unfair to expect programmers to be telepaths capabale of reading the "customers" minds to determine what's needed. (Customers may be managers, users, or purchasers.)
That’s a great point. Woody Zuill made a similar point in the interview I did with him on the channel. Maybe you can get some insight out of that one, I sure did! ruclips.net/video/EqjFFp36X4o/видео.html
Honestly, programmers should be paid to sit and think about a problem in addition to writing code. It is useful to ponder possibilities and experiment with prototypes before committing to a design, even with Agile development.
Everything being said on these videos is so spot on its spooky. I had to get out before i went insane or became dead lol! I so used to love programming too, but started to feel like i was working on a production line where there was no room to breath and the controlliness of agile as implemented was like living under stalin 🤣
Hey man. Your videos have some very good information and it's good to hear someone else mention the things that are bothering me as well; makes me feel less alone. Keep it up. I'd like to give some constructive feedback though - try to avoid upspeak.
On Agile development: There's no such thing as free lunch. Agile is useful for projects that in principle are unpredictable. It is not a remedy for poor leadership.
Yeah worked at a company that replaced most of the engineering leadership with agile scrum zealots with the expectation that things would be faster. Development is slow: solution sprinkle some agile pixie dust on it and problem solved. 2yrs later everyone brought in to lead the agile charge were fired and the company churned about 30% of the devs, including awesome ones like me ;) The thing was to agile wasn't necessarily a clear solution to the problem, we released annually (accounting software), to a known consumer base with a large market share. We knew what features we wanted next, had a year to build them etc. Breaking things into sprints and trying to dream up how to turn the big features into small user stories and prioritize backlog etc etc was ultimately all unnecessary overhead because ultimately being agile wasn't required.
@@musclesmouse Oh no, don't use the agile garbage. It's worse than anything else. www.google.com/search?client=firefox-b-1-d&q=coconut+headphones+agile Use this instead: books.apple.com/us/book/how-to-write-great-software/id623560706
Not a programmer but a designer. I can relate to this! We spend most of our time "moving stuff to the lest or right" according to the team's personal taste, and often get frustrated because I cannot meet the deadline due to bad communication!
I'm a programmer with little knowledge of design, but it is enough to know that it is a waste of time to try to move things a bit around for hours because someone with less design knowledge and less realistic self image wants it that way. Especially when he says things like "the customers like it more that way". No, they don't. The majority likes it as this highly skilled and knowledging person who designed the theme we paid for, has already done it. And on top, we don't have really have customers...
I was working on a functionality on a front end code and due to some backend issue my code was not working as intended , i had communicated that my code is correct and i think the issue is somewhere else , but the managers and leadership kept on nagging me to get it up and running asap ! Got 20-30 diffetent calls from different managers and leads , if its done or not ! It was one of the most frustrating thing i have worked on. Later when the back end issue was solved my code worked without a problem.
I like how you say different managers and leads. Have you noticed how much unnecessary people are there in typical software company? The best thing is, they don't have a clue about actual work because they never worked as devs but they are "leading" dev teams xD
Agree.. most companies I worked for do give you time to research.. and be creative.. one product I designed for a company ended up making em millions even tho they never asked for it.. I just built it and theh loved it. But like I commented on before.. you can blurt something out in a meeting at any time.. be forceful and confident and dont care what anyone thinks.. offer to do something like "ill sketch something out and send it to everyone:.. making the assumption that everyone wants/needs to see what you are sending.. then they start talking about it..
I prefer having a technically knowledgeable manager so that he can understand the intricacies of software development. However, the downside is that if the manager's skills are outdated, he might become a detriment to the project by forcing design decisions that although work, introduce technical debt, because the design, for example, becomes unscalable. I've had heated debates about design decisions in the past because a "technical" manager thought his perspective was the best, but he didnt appear to understand entity relationships and OO design very well. Also, I find that many engineers don't understand how to analyze requirements, which includes expressing the multiplicity of relationships -- e.g, 1 to 1, 1 to many, many to many, 0..1 to many, etc. If a design says that 2 entities must coexist (1 to 1), then the software MUST ensure that that relationship does not become broken. If the entities are persistent, then one can use a proper SQL database with transactions to preserve all relationships. If we delete one of the entities, we must delete the other, and vice-versa. With database transactions, the database will ensure that all changes occur or none occur. We don't want to have a situation where a relationship becomes broken, which causes the software to fail in peculiar ways. The ideal manager has a technical background and either his skills are current and he can make good decisions based on current practice that his equally educated team can support wholeheartedly, OR he's a manager that has the wisdom to step aside and defer to his engineering team to produce a robust design for the greater good of the project as opposed to a design that satisfies his fragile ego.
This is a really valuable contribution to the conversation, thanks for sharing. When technologists become managers they must decide that though they have a frame of reference, their subordinates doing the work know what’s best. And they need to let them make some of the same mistakes they did and learn. The only alternative is a technical micromanager and these are some of the most overbearing people to work with.
Had a boss that didn't feel the developers needed to know the big picture of what they were building. Like treating it like an assembly line building parts or some government defense job. He then wondered why nothing worked as expected. Many many years later when the company dissolved he finally understood.
In a wolf-pack, the lead wolf is always in the back, while the older, slower - but more experienced wolf - is always in the front, leading the pace. Hehe, not sure if this is transferrable to IT, but that's how wolf packs go...
This is such a problem in general in IT I have had some problems aswell with management naging about my project progress. So rest assure, its a gap what seems between what they know about IT or care to know or be told about.
Yes software development leadership has a big gap in training and education in our industry currently. I spend a significant amount of time on projects earning trust with management and educating them to try and help the working conditions be more conducive to knowledge work in a highly complex problem domain. I talked about this in many of my videos, an older one “Creative Software Development: Explosive Growth By Letting Go” gets a bit rambly at times (one of my first videos) but there are some good nuggets in there: ruclips.net/video/e48KPylwaB4/видео.html
@@HealthyDev I love what you do btw, it is so nessary to close this gap between leadership and IT personal. At the end of the day it will also boost efficiënte. I also want to take your advice to heart in your video's in general, as I notice it is really important in the IT workfield. Thank you for sharing your expertise and work experience.
It's important for companies to set up good incentive structures and transparency and lead by example. Devs may be given lots of time to do non-coding activity, think about the product, or experiment with designs. But at a lot of companies, non-coding is a black box, or product decisions are not transparent, or ownership/control gets more recognition than effective collaboration. As a result, devs may feel territorial. They see crowding out at the decision-making levels. They fear early-stage collaboration because of ownership optics. The dev policies to ensure quality are limited to code review or test coverage. Because devs are not made to share their implementation strategy at a higher level or how it's evolving, and have political fears, they go into their silo until their feature is done. Spaghetti code and spaghetti products result. I am not sure how to change this at companies where it's a problem. I can't blame devs for recognizing the incentive structure, and I don't think people at the top will care to change a system where they emerged as the winners.
You’re very insightful. Companies can reward cross functional teams instead of individuals. Some already do this, but it’s rare. There’s fear that people won’t be motivated if they aren’t pitted against each other. While that may be true in some industries, it’s completely baseless for an activity like software development which is collaborative knowledge work!
@@HealthyDev Thanks. I've tried to push these sorts of changes with not a lot of success. I wish I knew more effective tactics, or perhaps just how to recognize when to throw in the towel.
It’s a hard skill to learn, but not impossible. I encourage people with some of my other videos to learn consulting skills. It may not seem as impactful as better technical knowledge, but at a certain point in our career (at least in my experience), it is.
Been enjoying your videos, a lot of handy tips. I've got a question of a sort of a-typical problem: We've got a bunch of developers in Asia that actually like to be told what to work on, they do not like to take ownership of the Sprint Backlog. They're extremely used to a working and general culture where "following orders" was the norm and now they expect this type of leadership. What are some tips we can use to solve this?
You need an architect level technical resource who will hand practically pre-coded UML diagrams, sequence diagrams, and acceptance criteria to them. Or put in place a center of excellence for learning so these developers can improve their ability to deduce and own the work. Or hire more expensive developers with more skill.
This is interesting, managers probably should care more about the Scrum Burning chart, what i experienced first hand, that managers put lots and lots storie into backlog and demand to do majority of them in 2 Weeks iteration it was really messed up, only when i as consultant came in and started to protect team from such situation thing got better.
You have made some great points. I've been going through your back catalogue as I want to get better in my role and make sure we're implementing scrum correctly. Just wanted to note: sharing this with any management team might be hard when the title is "Why Do Managers Treat Programmers Like Children?". So although it's a nice idea to want to share this with your managers, it seems impractical given the click bait title that might make managers feel personally attacked.
Today's developers are tomorrow's managers. Feel free to take some of the points from this video and present them in other ways to management as you see fit. I want to see us all be healthier developers out there!
Nah, devs arent expensive, its just that were basically halftime at the company, the other half gets wasted by management and with no code being written. Worse if they dont get code and everything turns into a ball of mud 'cos of their requirements and everythine slows down further.
Exactly - I love programming while Agile Scrum makes me hate my life. Then they have this militant style like HR would. Worst of all, they put non-programmers in charge.
#9 is my favorite for me. When the developers loose sight of what the code they are writing is good for, they can't provide creative ideas on hw to improve the product.
Hits the nail on the head. Exactly list all the problems I seen. But to convince mangers and companies of this message is like deep sea diving with nothing but a speedo. Fat chance management will listen.
I have been through having to give daily status reports directly to my manager. I had been working for the company for about 4 months at this time. It's just as you said. Didn't even feel like he was reading them and sometimes he wouldn't even respond. Felt more like an authority move. Very insulting for sure, and only hindered progress.
"Changing scope has costs associated with it." Yeah, I had a job where scope was changing almost daily due to ban planning and things not being thought out. Then management would turn around and ask why things were taking so long and why we couldn't meet our targets. Yeah, never again.
"Tired programmers make rash decisions." Yes! Been there done that. LOL :-)
4 года назад+1
I am getting more and more frustrated with this "Capitalistic" software development where quantity is more important than quality. Over the past year I've had several issues with hardware that I bought and it didn't work as it should. Most recently I bought a GoPro Hero 9 which has some dead pixels (basically unusable) and now have to wait for them to release a firmware update which hopefully will fix the issue. I guess the underlying problem to all of this is greed, everyone just wants to make quick money (The ones that already have enough want even more)...
Sound like there are a lot of pointy haired bosses like in Dilbert out there or it's an office space environment both which seem to be bad for the creativity and making sure the quality is in whatever the developers send out to be the final product .
The best video on RUclips regarding management of sw development! Scrum is a scam. It looks like its not meant to make a project more successfull but to mess up everything.
This issue is due to the economics of the business. Developers need to study the top of company, and understand the nature of the business before joining. There are many "malignant" or even "predatory" dev shops that's literally make money by squeezing labor from a small dev team. These are usually small to medium sized business that typically sell software to the government, and love to hire many cheap junior devs. They place an Agile management which is to simply used for analytics about dev performance... So in my opinion this is a labor issue or even political.. We developers need to form a UNION!!!
15:14 Well said. Yes, after a while people get a very narrow focus on the local results while it feels more and more like a rat race. And Sprint reviews alone are not necessarily helping much. It's much better to stay in touch with the testers, and have a look at the whole project's output from their point of view, at least from time to time.
It would be nice to see a video from the opposite perspective, to help programmers understand why management asks for updates, why timelines exist, etc. A lot of the issues I think that stem between management and production (whether that's software or widgets) is a lack of understanding.
Thanks for the feedback Luke. I plan to do some of this, but the way most projects are managed today doesn’t match the characteristics of software. I’ve talked about this in prior videos but I’ll be sure to revisit it. Appreciate your feedback. I made a video called “Healing the rift between programmers and managers” so I want to see this happening! I just find much of the process advice out there caters to managers and not those doing the work.
Usually the problem with middle managers is that if they have no clue about software engineering and therefore they are unable to effectively negotiate deadlines with their superiors. With the advent of scrum, middle managers mutate into micromanagers and they rarely negotiate with the Product managers as they are technically unable to do so
Upper management at my company wants daily status updates for who they view as underperformers. There's generally no positive feedback - there's either silence or negative feedback about minor things. This makes us feel like management does not trust us and only uses these status updates as a way to nitpick someone's work. There's no incentive to try new things or take on work that has any risk of not being completed by the estimated date. It will be nitpicked during these status updates. This hurts the company in the long run and is causing me to actively look for a new job.
Bingo. Sorry you're going through this, in my opinion your evaluation of the situation is right on. If all management does is actively look for problems that's all they'll see. I talked about that in another video that might be relatable to your scenario, "Is It Safe To Make Mistakes On Your Software Project?": ruclips.net/video/-dhLuNcMUIo/видео.html
Just a question, what’s acceptable speed to get things done? Because if I get 10x the work done no place would pay 10x the pay. So what if people are just being lazy? And I’m not talking once per sprint I mean consistently?
Point 7 I would just say be careful about what features and ideas you suggest if you're a developer. For starters no one is going to give you a 100k bonus because you 'thought up a great feature'. If you pitch a generally good idea to the product owner they're probably say something like 'Yes we've been considering something like that for a while but we've not quite there with it yet' even though they're actually trying to work out how they're going to pitch it to the higher ups to make it look like they had that idea all along. In all seriousness there is always a risk you're just going to annoy the product owner because it can look like you're trying to step on their toes or undermine their authority. You're ether coming up with amazing ideas and making them look inferior or they're just having to work out how they're going to diplomatically shoot you down all the time. Generally speaking mastering the lane you're assigned to and will be ultimately evaluated on is better than trying to cut into someone else's.
I’d say that’s true in command and control corporate cultures. In more cross functional teams the whole point is to minimize the lanes. Meaning you still have specializations from a division of labor standpoint but there’s team ownership (and rewards) so people can contribute ideas outside of what might traditionally be a lane. You of course have to budget differently and you’re changing people’s motivation from individual to product - but you’re getting higher engagement and creativity - which is where the profit generating theories of value come from. These are slow moving changes in our industry, but they are having some success at companies willing to try them because they do have aspects that gel better with the fact that software development is collaborative knowledge work and not manufacturing.
@@HealthyDev Do you think this is getting more or less common? I know Agile is newish but as the field grows, I see more and more pressure to specialize. The harder it is to find a skillset, the less management wants people with it spending time on other things.
In that regard I think being a junior dev is often more fun than senior, if the company gives you room to explore instead of pigeonholing you at least.
@@qubitblogonmedium6160 I'm not sure I have an opinion on whether it's getting more or less common. There is pressure to specialize because of the complexity of the field - but there are also leaders and managers who recognize potential dangers in it and setup their culture to accommodate accordingly. The future is still wide open there...
I agree with the contents, as it depicts a rather sad picture of software / contents development today. I worked on both ends, so I believe I can safely say the misunderstanding / ignorance / idiocy are on the rise - possibly a sign of modern era, which I'd put as a 'quantity over quality' approach. Phrase 'just make it work, we'll fix it later' still haunts my memories. My only comment here - I think I'd change 'leaders' to 'managers' in the title - there are very few leaders, but 'waaaaay' (say it loud with pathos) too many managers. In other words, every other idiot can be a manager (and 'waaaaay' too many are), but ('waaaaay' too) few leaders are actually managers.
Working as a mechanical engineer.... it's the same for us, too. When you have to explain for the 20th time why a 4-week long environmental test cannot be done within one week, it is soul-crushing. xD
I am a php programmer going forward for web app development throught this route with no cs degree. Wanna be a software developer in near future. But nowdays i am loosing motivation because the expectation of people are so high, i'm having a hard time. Somerime i feel like a fraud
It’s common for us to feel like that, I did a video on imposter syndrome you can watch that might help. I’m of the opinion that you’re absolutely NOT a fraud. When I feel uncomfortable with something it means I’m growing. If you can find a way to accept that feeling as a necessary emotion for growth, you’re actually ahead of many developers who might think they’re further along than they are. Don’t give up. You can do this. I have to fight with this feeling every time I learn something new. If you learn to embrace and master this part of the job, you’ll have a long career and never get stuck working on outdated technology!
I’m not coding currently, I’m actually in the market for a new consulting contract, or perhaps a product management or coaching gig. My favorite stacks are ruby and .net, but I’ve also done quite a bit of java over the years. Have only messed with node on the side. I like swift for iOS and pretty much all the BI/data manipulation technologies. I also like working with AWS and Azure.
Hey Jim it's a 1971 square badge Gretsch bop kit. I write stuff usually from singing and acoustic guitar, then add whatever it needs. Sometimes just guitars, sometimes drums/bass/synth, it all depends. I just do it for fun.
I didn't watch, but would answer the title from a social psychology perspective. (I like to head straight to the root.) ... *It's probably a jocks-vs-nerds thing.* Funny-sad anecdote: I was in a meeting about career development at a company, with people of various ranks/departments present, and the guy did a Powerpoint presentation where he explained two major career paths: "professional" and "managerial". I found it disturbing that I was the only one grinning and hardly able to suppress a snicker. Was I witnessing the widespread absurdity of the business world meeting utterly jaded people who had normalized the cynicism of it? Or were people afraid of losing their job and trying to practice sucking up by going along with the BS? - (I didn't work there for much longer. ... And it didn't get any better. ... Now I'm burned out.)
The cultiness annoys me to no end. Until we can accept that a fashion loving extrovert woman can code as well as a stereotypical geek guy D&I will be limited to tokenism and innovation will be limited to group think.
Great suggestion. I may talk about this more. I did talk about it some in the video "New Framework Disease (NFD) in Software Development": ruclips.net/video/NCEABmfE2YQ/видео.html
Our VP of software engineering used to say all the devs did nothing but drink coffee all day even though we brought every project in on time. Our CIO knew better. VP is no longer there lol.
My favorite was a TSA who was trying to do testing and the PM was calling once an hour to see if they where done, he finally moved to a different meeting room and would not tell anyone where he was, he got it done after that...
Yep. Some of the best developers I’ve worked with spend more time educating management than writing code. It makes the job better for everyone else, but it takes incredible patience
@@HealthyDev welcome to my world. I have to spend weeks debating why code reviews are good. Management want me to re-write everyone's code all the time because they think code reviews slow development down. Lol. But no problem with 2 weeks of rewrite.
It's a very interesting topic told from perspective of a programmer. I wonder if you'd like to do something similar but from manager's perspective. I would love to have a chat or at least exchange some ideas. I was a programmer for 15+ years (but coded almost whole my life) and now I'm a manger for 5+ years.
Full transparency I'm focused more on helping the "line workers" than management in this channel - but I do understand it's a two way street. One of the other videos of mine you may have some feedback on (or relate to more?) is "Healing the Rift Between Programmers and Managers": ruclips.net/video/_TlQb8MKCNo/видео.html
quieting shitty corporate job now where they treat like a child, asking for updates every hour and sitting on our heads all the time pressurize like hell..i cant do programming with this constant pressure.. will drive tractor on the field and do farming in open in positive healthy environment :)
Let's be honest, though. Some developers could do a better job of communicating their status, pushing their code, commenting in their tickets. I don't think managers in general WANT to nag. They do it because they feel otherwise helplessly unaware of where everyone is at.
While this is true (human behavior runs a wide gamut) as I talk about in my video on daily standup meetings we have technology for management to know what’s going on now. They’re often too impatient and want to waste time asking follow up questions about status they already see in Jira or another tool thinking somehow they know how to optimize work better than the people doing it! If a manager can’t trust their employees, they shouldn’t hire them...
I'm one of those developers who is not mature enough to come up front when a task is taking longer. Mostly because they'll grill me for it. Or they'll ask for overtime since it's "my problem"
I'm in such a position where I'm being pressured. I'm the only developer building an ERP/CRM/E-commerce solution. 'Boy have I learned a lot about my limitations. But I have to produce so that we can make our customers happy so that they pay us.
To put this succinctly, success emerges when from trust between managers and engineers. Without trust, everyone becomes miserable and failure is likely. Now... how to get that trust... hint: you won't find the answer in any book about algorithms or frameworks.
7:59 - *and* to top off it being more complicated, how are we supposed to know that now this is going to change mid-stream? Management will get themselves tied up in knots if they don’t understand this. i.e. Now the system is _so over complicated_ thanks to the scatterbrain, it takes longer to make a simple change and now we _hope_ that they don’t change the scope while we’re spending that extra time to get the request done. Ideally
On the being agile part: We have one very innocent sounding change which comes up a lot and causes us a lot of headaches. On one of our internal systems we have a lot of data capture forms, these include a lot of dropdowns. We ask many times when adding these that they will only ever need to select ONE option and they tell us without a doubt it will only ever be one. Later down the line many of these change to be multi-selects. They wouldn't even tell us how they want this to be reflected in the reporting or document generation 😂 I'm sure when I said if they need to select ONE option or MANY options all programmers will instantly click what type of issues arise here xD
Oh, that's gotta be flipping annoying. Either you gotta go back and refactor your data model each time, or accept "preemptive denormalization" by designing it to accommodate all the changes anyone might ever want upfront, or (most likely, I'm guessing) completely sacrifice type-checking things and having a consistent data model at all. (Maybe just throw it all in MongoDB and hope it becomes someone else's problem before you have to face the inevitable consequences?)
Its amazing how some of the biggest projects in the history of mankind such as "The Manhattan project" did not use Scrum, Agile or any other management methods
Thats because it needed 0 bugs :) really 0 bugs... that was the atomic bomb... if one very small thing didn't work than everything else is doomed.. in software agile you can many many small bugs
it helps immensely if you have one big goal that does not change. you got essentially an unlimited budget and manpower. that is very different to a software project.
@@samsarasap4911 True, the methodology implies that the final result is so agile that it produces not only all the desire effects but also some bugs( as a bonus...)
@@qdeqdeqdeqde Great observation but the question still remains: if a software development methodology produces errors in the final product than its simply not good enough, so why do we need all these consultants and Agile/Scrum experts to tell an organization how to do their job?
I actually prefer being asked for status frequently as opposed to being neglected for long periods of time because at least I know what is expected of me
Does your CTO, Product Manager, or Project Manager know how to treat programmers?
Skip to points:
01:23 #1 Programmers Produce At Different Rates
02:27 #2 Frequent Status Doesn't Get Things Done Faster
05:05 #3 One Task Doesn't Control A Project Timeline
07:08 #4 Making Changes To Be Agile Has A Cost
09:00 #5 Programmers Deliver Faster Through Creativity
10:04 #6 Programmers Need Rest To Be Creative
11:39 #7 Programmers Can Identify Valuable Features
13:19 #8 Programmers Forced To Hit Deadlines Cut Corners
15:12 #9 Programmers Forced To Only Code Lose Focus
I like this. I feel like every RUclips video should do this.
thanks alot!
too many managers, nuff said
I would add the leadership usually do not understand value of code maintenance and refactoring.They see it as additional cost without benefits.
@@jakubrinkes1896 Agree completely. I believe some leaders do understand, they are just under pressures that feel stronger than having to account for this. I talked about overcoming that in my video about Saying NO so people will listen.
When I was at a consulting agency, we discussed this a lot and decided we would never line item this work. Meaning we would assume a percentage of time needed for it and do our best to include it in estimates. But we never called it out as something that could be "removed". If we ran into an opportunity where we needed to do a significant refactoring, we spread it over each task or sprint. This requires iterative refactoring - which I think is a very valuable tool today. Refactoring in steps is possible, but tricky without a lot of experience sometimes. YMMV
Feels refreshing to hear all that. All around I see outside people thinking we are machines. Thanks.
Thanks! This channel is all about software developers and the people that work with them treating each other like humans.
Nobody thinks so. You make them think so.
yeah, exactly.
I got into software engineering for the creativity & innovation, because it's both art & science, both of which I love. I've worked in some environments that value software engineers holistically and others where creativity is completely abstracted into other roles like product manager and architect. I'm motivated by impact rather than competition, which has inspired me to develop a broad skillset and embrace continuous learning. As more companies use HackerRank type assessments as their main hiring and placement metric, I got the sense development is for speed demons and creatives like me belong elsewhere, a shame considering how much value creativity can add in the fast paced field of tech. I figured my view of code as an art form rather than a factory style plug and chug process was a misconception from my liberal arts college. While I'm happy at my current position, my past experiences still make me wonder whether to stay in an overall industry that seems to value my work style less and less. Coders used to be perceived as creative geniuses in the media (overhyped imo but valued for the right things.) Then came the code monkey era. It means a lot to hear creativity is still a software engineer's most valuable asset from someone with your level and breadth of experience.
Corporations that use leetcode and hackerrank or “prequalification” companies like toptal to hire engineers get what they deserve - no insight whatsoever as to the talent of their hire. A lack of creativity is what’s causing the cost of development to rise so fast. Software development is closer to screenplay writing than engineering. You have a story you need to tell but there is amazing freedom in how to pull it off. It’s a convenient lie our industry sells to unknowing people that don’t know how to evaluate candidates that someone passing a coding interview is a good programmer. It literally just tells them they know how to study a test.
@@HealthyDev This is what I tell people when they ask me things about tech stacks or languages to learn; programming isn't about code; it's all about creative problem solving.
Amen!
2 years old video. More than a 1000 likes and only 7 dislikes. The numbers and you speak the truth.
now i just need to figure out how do I show my managers this video without seeming passive aggressive?
Yeah I probably wouldn’t do that unless you have a pretty close relationship with them. I put a couple of the points (I think it may have been #2 and #7) in the #HealthyDevTips playlist on my channel, but even a single one might be too incendiary to the wrong person.
I’ll continue to do videos on communication and basic consulting influencing skills, hopefully that can help everyone pitch some of these ideas the best way possible to people that might benefit from hearing this information.
A commentator on Reddit where I posted this felt my tone might be too developer-slanted to get leaders thinking in this one. Depending on the person I’d have to agree with him.
For the right person, who you have a good relationship with and knows ahead of time you’re not trying to be critical but to inform, they might be able to watch this with an open mind.
I am thinking i'm going to try to take a teach by example approach, I have my scrum master certification so I will ask for an additional role as a scrum master on another team for a bit of extra leverage to fight certain things. If I can prove it is effective I may be able to lighten the load for myself and my own team.
@@HealthyDev yep, those videos title are not helping either ^^
@@ryusaikou1604 If you have the good relationship that Jayme describes, you can link then to this as an insight to see things from a developer's perspective, so they can understand why something is frustrating when it seems reasonable from where they're sitting.
U r responsible for what you say, not for they understand
Definitely a video that was needing in the industry.
There's such a gap between traditional management and the modern software methodologies (ie: Scrum, DSDM, etc.) that it makes a gap in communication and expectations between software engineers and their management.
Thanks for your support. I realize just kicking a video like this over to managers verbatim probably won’t go over well. But I am always trying to help managers understand the implications of their assumptions so they make better decisions, which I know many developers also do. Hopefully people can pick one or two of these points and start a conversation about what it would look like to make the work environment support reality better.
One of my favorite projects was one where I was given a rather expansive user story by the client. I was then able to take several hours to write up a concept for the different features that would need to be built out to handle everything he wanted. He then looked that over and made some adjustments to his thinking based on things he hadn't thought about that my document brought up. I made adjustments based on his feedback and got to work. There were no deadlines other than having something the client could test out in about a month. Managers left me alone for the most part and I was able to come up with creative solutions without feeling constantly stressed, I was able to think when I needed to think and code when I had a clear direction. It allowed me to build the project out in such a way that it wasn't overly rigid and could handle change and potential expansion. One day I might write almost no code, others I wrote a ton because the previous days thinking and planning facilitated it. Every now and then I would think of something we hadn't anticipated and have to discuss it with the client. Then I would continue forward based on his input.
Once I had the mvp shipped, the client had several additional things he wanted. Because I was allowed time to make a quality implementation initially, it allowed me to add on the additional requirements easily. The final product was shipped after a total of 2 months with all the bells and whistles the client asked for throughout several iterations after the initial build was complete. I actually enjoyed the work and was able to have a good work life balance throughout.
After this project I was thrown into a tightly managed scrum style project with 2 week sprints and estimates they treated like commitments. There was no time for thinking, just implement, implement, implement. It didn't matter that the tech stack was almost completely unfamiliar to me, they just expected me to learn as I went while still hitting all the desired deadlines. I was more exhausted after the first 3 days on this new project than I was after 2 months of the other. In my opinion big Agile is evil and ineffective, as is scrum. I think Agile is almost solely responsible for the massive developer turnover companies experience, developers constantly looking for greener pastures where they will actually be treated like human beings rather than a resource to be "maximized" until it burns out.
Programmers are forced to work with blinders on while the project manager(non technical employee usually) tries to control the reins(so they can justify their existence). It results in more work later because programmers aren't allowed, and given time to see the big picture or given the time to plan ahead, make adjustments and come up with creative solutions that will end up solving a lot of the problems before they happen that the project manager, project owner, scrum master and agile coach aren't going to know how to anticipate. The whole rigid 2 week sprint structure isn't actually very agile at all. If they just fired most of the management who are little more than parasites feeding on the developers and allowed the programmers to manage the project with the client, the client would save money and the implementation would be closer to what the client actually wanted and likely be finished as fast or faster. By turning programmers into code monkeys who are forced to work on tiny tickets every day with the hopes that all those tiny parts result in some big functional thing, they take all the enjoyment out of coding and make it an endless sprint through a dark void, with constant stress and no time to ever stop and think about where we are headed.
Hey there, thanks for sharing this difficult story. I'm sorry you went through this, and man have I been there.
I hope you can find another position that lets you do great work and not be micromanaged. Sometimes it's the honorable thing to do to stay somewhere that isn't great to pay the bills. But I hope you listen to that part of you that says you can do better (when the time is right). Hang in there!
Nice video!! One informal conversation in front of the cofee machine can tell more about the project status than daily stand up meetings. We love telling about our new sw module features or complaining about technichal problems/bugs, not being constantly checked up.
I think these consulting tutorials are great, but what really hooked me to this channel was the sun-glassed story times, where you tell old anecdotes about past experiences, and how that gave you more insights. It very cool, because it brings a bit of spicyness and tension to what you're trying to convey. Besides, everyone loves a good story.
In the ideal world, programmers would not have to sacrifice the long-term project goals to satisfy some short-term whim of somebody who does not know what he wants. The decision makers do not understand the full extent of their own limitations. They are bombarded with the motivational quotes that sometimes are frighteningly far from reality. They have one foot in the fairytale world. People, in general, want their ears tickled so nothing will change for the better. The leaders will continue to have their fairytale visions and confrontation with the reality will continue to be a form of the blame game. Perhaps we should start educating the leaders about their own limitations? Do you think it is possible?
I think it’s possible. The major goals I have for this channel are:
1. Help programmers and managers understand each other better.
2. Provide support and solutions for people in suboptimal environments to make the best of their situation.
3. Be a place where developers and managers can support each other’s struggles.
4. Help current and future technology leaders foster a culture of safety and creativity so people have fun when they build profitable software.
To understand each other's struggles you also need to understand each other's limitations. To foster the culture of safety we need the culture of trust. Lots of things depend on each other in very complex ways.
Great insight. I totally agree. It’s a complex problem, I’ll keep trying to put these ideas out there. Appreciate your support!
Thanks for this video. You really summarize a lot of what has been going on at the projects I've worked all along. Sometimes I feel like I'm the negative guy that thinks about these issues at work when almost all the rest of the team don't really seem to care. The thing is that I'm not part of a project only seeking for the next paycheck; I want to make big impact in my everyday work. I think it's soul fulfilling when work is done and it's done well.
Thanks again
You’re very welcome. I too love work when I’m able to make an impact. I guess over the years I’ve had to adjust my expectations of what that impact looks like and try to accept things I can’t change more. It’s an ongoing struggle - and it sounds like you’re already doing that!
your channel is too wholesome, man. Thanks for doing this.
Thanks for the feedback and thanks for watching! 👍
Meetings have a cost. A Managers day is sectioned into (8) 1 hour Meetings. For them, this is routine. Developers day is different. It costs him more to start and stop. For instance if you set a meeting at 10am, you just busted up my whole morning. The thing I need time to do, is not getting started, because it has to be put down for the meeting. There is nothing wrong with a managers schedule, its what they do. Meetings are also needed with the team. But they should be very few, and very focused on one thing. Throw in a Project Manager, (Ahem , a Scrum Master") -and you get more meetings. I believe this is the core reason for conflict on projects and timelines. Its the single most anti pattern there is. AND nobody can predict the future.. HELLO COVID!!!
Especially number 2, management nagging "are we done yet?" like a six year old on a road-trip repeats "are we there yet" stresses the hell out of me.
How the heck do they expect me to focus on complex code, while due to the same occurrence parents are deemed incapable of driving safely due to loss of concentration.
The second most infuriating thing to me is management constantly pushing other non-project related tasks in-between the current project, deeming it an obligation to interrupt my actual project-related tasks in that process. Then acting like those completely unrelated tasks where part of the running project expecting no delays. How do they keep coming up with such nonsense?
The third one is management micromanaging your every step, thereby slowing you progress down massively.
Because you became slower they tend to increase the amount of micromanagement a bit more which in turn slows you down even more...
Rinse and repeat...
For me it's getting into 'the zone' that I find mentally tiring and draining, not staying inside the zone.
Leave me in my 'zone' and it wouldn't be an exception that 8 hours passes without me even noticing, if I'm left uninterrupted I can keep working like that easily for an entire week.
Force me out of my zone for 3-4 times on a Monday morning, and there are occasions where I find it impossible to re-enter my zone for that entire week during normal work hours,
just because I know it's not worth it and I can best postpone the real work to this evening when I'm home and left uninterrupted.
On working from home days I also tend to program between 7 to 10 am, followed by code cleanup between 12 and 1:30 pm. I then tend to complete my workday with 4 to 5 more hours after 5/6 pm, just because those are the hours management won't interrupt me trough phone, skype or mail and I can get some actual work done.
But the real question stays the same, how the heck do you explain these issues to you manager and non dev colleagues when you already tried each polite and civil way possible without any improvement or results? I would actually argue that the current pandemic forcing us to work from home thereby improving work efficiency, actually saved our current project over here.
But it's already clear that management won't see it that way, as they're already talking about returning to the office in the midst/start of the second wave.
The work from home has become a nightmare for us. We had clear boundaries between work and home before the pandemic but now texting at 11PM is totally fine. Can you believe my manager said, "Should we decide the deadlines by asking you?". That's the point I knew this situation is beyond repair. Time to cut my losses and move on.
@@sirrus3009 Just ignore the message or make sure to keep private and work numbers separated.
Once you answer on such late messages you are literally doomed.
I don't know how youtube suggestion algorithm works, but all that mentioned in this video I constantly trying to explain to my current project team especially last week, and now I encountered this channel that talks about exactly the same things. The problem is now I'm afraid to even share this video with my company because it will look like that all I'm standing on is just a bunch of words from youtuber and not my own opinion. It's a shame how miserable I became :( when someone treats you like a child you suddenly became one. Anyway, thank you for your videos and experience
Same here but I think it all depends on how you transmit the message to others, so don't feel that way. In my case I'm enriching my notes about this by using this video's pacing for some ideas. Surprisingly these are ideas are in some of our minds already, so we're not alone
@@Stratbass yes, recently we canceled pointless daily status meetings so I succeed at least in that
This is my 25th year as a developer. Almost all of what you said is like an echo! The best jobs I've had is where a team lead and manager were developers because they understand and can relate that to non technical managers. But even then, the politics kicks in and you end up working overtime for no pay. And that's the good ones! Others ignore technical debt and blame the developer for not fixing everything. Those are the ones when you feel like you're in a Dilbert cartoon!
Omg this is so true. I blame it on too much non tech people in software industry who just don't understand how the process works. It is ok for upper management to be non-tech, but guys who are directly involved in development process as well as middle management should have tech background. They should be a buffer between upper management/investors and developer teams to allow developers to be productive but at the same time know how to talk with other side and keep them satisfied. As you said in another video...there should be a focus on business value and not on features/tasks. That is the job of middle management to handle. As I noticed in most of Scrum teams there is a non-tech PO who is actually "leading" dev team. Put scrum master here as well with their bullshit and you get typical software project now days xD
Some leaders are afraid of a single or a few expert underlings having more real power or impact in the company than themselves and for this to be visible. They might try to "flatten" the terrain in various damaging ways. Dreaming of a team where every dev can easily be swapped out with another if he or her misbehaves.
Power is what it is about.
I was in a similar position where devs would be bullied to produce results, and were even put up against each other to put pressure on each other to get things done.
I realized at some point when pressure is put on you or anyone, it's passed on to the next person and the next etc as automatism, something you've learned as an acceptable method, causing a chain of misery and frustration. It's not acceptable at all! After realizing this I cut the chain and reflected it back at the source, because once the chain gets going it will circle back to you to bite you again, and even harder. It may take days, months or years to circle back, you may have forgotten it long before it's back on your plate. Then another manager tried to do the same but I had a better trust relationship with him. I explained the above and he understood after some soulsearching. We both quit the job and went our separate ways, found a really good place to work in. Now no one can put pressure on me except myself, it'll be my choice and no one elses. People are really good at putting pressure on themselves already, they don't need anyone else to do that.
This change of attitude totally changed how I work with people and how I'm treated.
Now, whenever I'm faced with such a person, I'll increasingly resist and be unpredictable and uncooperative, questioning every decision. Once they treat me with respect and are more reasonable (even if it's by accident or unauthentic) I'll immediately switch to being cooperative and be predictable, letting the person know I appreciate him or her. It'll totally surprise, even shock them. They'll fall back to the pressure and control pattern a few times thinking you are under their control, but once the positive change sets in, the atmosphere changes a lot for the better. A trust relationship is now possible to be build up. And for the person in question too. They are being pressured and maybe bullied too and are just passing it down to you. So send those shockwaves back up the command chain, it might just improve the whole company, even if it's just a little.
My favorite is expecting same time estimate with changes given at 11th hour. They really think we just sit at our desks and drink coffee.
Agile development looks like formal name for leadership constantly changing directions. Turns devs into firefighters. We end up fighting the next fire(sprint). Agile is another name for Ad hoc type development. Devs churn out lots of code, but nothing is really reusable.
When I have brought up these items at the companies I've worked at, I get blank stares and push back and curt replies. "Just try your best" and "Just get productive" and "We need to track progress"
But the issue is coming from them, they don't know what they want and have very little idea what it takes to get it done.
I'm hoping the next position takes into reality these points.
That sounds like insecurity is a problem there, too. I see the same problem around me. Managers feel powerless, because they have no clue what their programmers are doing, sometimes even have a clue what they are ding themselves. Micromanaging gives them the feeling of being powerful and in control, even if they don't understand what you do, they can make the hierarchy clear by being the person who demand something.
I don't think programmers need to be managed so much. Assistance would be much more useful. But this would flip around the hierarchy. I think, this is an even bigger fight and those not so skilled managers have a lot to loose.
@@ecm9251 they seem to think by hiring knowledge workers and managing their work they can do knowledge work by proxy
What folly
It's therapeutic to hear some of this stuff voiced 👍
This video is soo good, I'd love that some managers or CEO's would actually see that. Especially on my most recent company.
One of the things to also have in mind is that if you keep the pressure up to deliver on the deadlines you will in the end lose out on the (few) next deadlines. Just because of all the points mentioned. Bad maintainable code, not using best practices and very spaghetti systems will lead that you may need to refactor it because some other features, using the system will not work with the current implementation.
Just wanted to add that. Great video, I'm quite tempted to share it with some people I know could need that video for sure.
This guy is the truth. 36k views only? What a shame.
This is the key. Requirements Analysis! Managers don't understand that you need to know what you're doing before you start coding. Analysis is about describing what you want to do and describing data in detail and the relationships between data.
Once, I worked on a project where my team worked for an entire month on analyzing the requirements for an internal installer application for our company's software. Management was concerned that a month had passed and we hadn't started coding. We told them that we would deliver in 4 months. They changed our time line to 2 months. Guess what? Our first solid delivery was 4 months and worked elegantly and exactly how we envisioned. We told them the truth about our estimate of months and we were right, and no -- we didn't sandbag. We still had a few minor tasks to complete but we delivered all of the core functionality when we said that we would originally, and the engineering teams and test groups loved the new installer.
After doing such a great job, management put most of us on bug fixing. I recall fixing 75 bugs during that year. My manager at the time who was also my manager for the installer project said to me one day, "Bruce, I like that what you fix stays fixed."
Awesome testimony to the importance of requirements. I believe part of the reason commitments made on oversimplified work has become so common in our industry is at least partially due to the proliferation of user stories without understanding their intent. I talked about this in one of my other videos “Can User Stories Make Software Projects Late?”. I wonder if you’ve experienced some of this: ruclips.net/video/NavlPobhj7A/видео.html
@@HealthyDev Yes, "intent" is an excellent choice of a word. Intent is important in life in general. Why you do something is more important than what you do. Intent represents the why.
I find that the biggest challenge in software is dealing with fragile egos. Rarely do I tell people that I graduated from MIT (Bachelor's 1987). Why? Because it creates grandiose expectations.
Some ask me what is the biggest lesson that I learned at MIT. Well, I learned how to solve problems of course, but more importantly, I learned that I know very little. The experience humbled me.
So, I put my ego aside and I've told my boss recently that truth does not offend me. Better designs or ideas do not offend me. They don't have to come from me. It's an opportunity to learn. I want our product to be better for all of our sakes. We can be honest about the issues and work to solve them in the light of day.
Also, if a design is not necessarily the best, but is still sound, we can always refactoring it later as long as it is robust despite its limitations. I've learned to let some things go.
As for the user story,, it can be a useful tool in conjunction with use cases, but they can only work well when you have a great scrum master who is skilled in the practice, and a team who is skilled in agile, but yes -- there are challenges when not applied correctly. I will listen to your video on user stories.
By the way, great channel. I appreciate your stories and wisdom and will continue to listen.
Yep, it really makes so much sense to keep a developer, who's task is late, constantly interrupted and incapable of working due to that. It's really hard to imagine a more effective way to make sure the task will never get done.
🤣 for real.
This is the SINGLE BIGGEST PROBLEM I have with Scrum: the idea that I have to tell someone everything I'm working on or attempting. Don't get me wrong - a scrum can he a wonderful place to say "hey - I used all my research and backup hours for my sprint and I still don't know how to code this sprocket - I need help" so that (a) you get help and (b) managers and other devs can pick apart if there wasn't enough time, if they needed more context, etc. instead of saying "well, um, you know, we really needed that to be done" and kinda projecting this "well you're a developer so you should know the things" expectation.
Yes... we SHOULD know the things. But when we do project after project after project and are expected to research and solve problems faster and faster, the learning time quietly goes out the door, my dev confidence drops and my engagement level wanes, and then the problems really begin.
Good point there. I completely agree with that. Scrum just kills your productivity because you don't have time to sit down and think about a problem for a day or two if it is a complex one. Instead you are obligated to "produce some value" till next daily.
Really glad you're doing this channel, keep it up man. I think your work is fantastic, and though only a few episodes in, I'm already feeling the need to jot down notes when you're talking.
That's the sign of a good RUclipsr, with good experience, AND they're a good educator. It's not common to see all three but you obviously know you've got that already. What surprised me is hearing you easily wrap together multiple contexts whenever you describe the common workplace perils programmers would value knowing about.
Off the top of my head in your culture change episode you discussed the incidences and lessons learned from the perspective of: a new hire, a proud young programmer, an underpaid line of workers, an unfit project manager, piss-poor leaders, new insecure colleges, and so on.
Oh there's so much more, the debriefing, reflection, and autopsy must have occupied your spare thoughts for some time after that project ended.
After summarizing the gist of the stakeholder's perspectives you offered your thoughts towards avoiding and mitigating the damage in similar situations in the future. Tossing in the various attitudes and behaviors required to stear through the situation (from your POV, the business owners, etc..) was pure lagniappe btw.
I will binge watch your work over the wee… oh god none of that is what I came here to say. The cuts you do with the camera in this episode are fucking brilliant, but it's in the "it's a clever solution to a problem nobody else would ever of bothered to notice" kind of way….
I had you up on a second monitor 🙃 while I was working, and noticed you kept teleporting back and forth 🤨 to either side of the screen. 🤔 I just stared at your episode for a minute thinking I'd noticed some telltale sign of a new RUclipsr 🤭, but then it hit me,😮 it was a cinematography (dare I say 'style'?) decision, 🧐,because you were switching 🎥 camera angles every few moments 🎥 to keep the imagery active… simulating the effect of cutting to multiple cameras. 🙀
Why move the camera? You can just switch sides of the screen periodically using the magic of editing, and if you only stand in the same spots (I noticed) it doesn't look disorganized, and our brains area already accustomed recognize the that pattern of editing.
It's too small of a thing where could really brag about it, you'd sound like Rick Santorum talking about his lucky sweater vest. But it personifies the software designer wavelength so much you'd of had to of known programmers (or video producers) would surely notice it.
I hope you don't let anybody talk you out of those little Easter Eggs in the future, and hopefully they'll mature along with the rest of your channel for years to come. Good luck. = )
Thanks! Appreciate the support. Lol yeah the camera cuts is just me trying to make a pretty boring environment a little less so 😉
Keep up the good work Jamie!
Confusing activity with productivity is a big mistake. The most important step in any project is finding out what's really required. It's only when you show people exactly what they asked for that they start to understand what they really want. The times I've failed have usually been when I've failed to define the requirements properly. It's also unfair to expect programmers to be telepaths capabale of reading the "customers" minds to determine what's needed. (Customers may be managers, users, or purchasers.)
That’s a great point. Woody Zuill made a similar point in the interview I did with him on the channel. Maybe you can get some insight out of that one, I sure did! ruclips.net/video/EqjFFp36X4o/видео.html
Honestly, programmers should be paid to sit and think about a problem in addition to writing code. It is useful to ponder possibilities and experiment with prototypes before committing to a design, even with Agile development.
Scrum actually should be like this. Half of the sprint development, half of the sprint analysis of the next.
Everything being said on these videos is so spot on its spooky. I had to get out before i went insane or became dead lol! I so used to love programming too, but started to feel like i was working on a production line where there was no room to breath and the controlliness of agile as implemented was like living under stalin 🤣
Hey man. Your videos have some very good information and it's good to hear someone else mention the things that are bothering me as well; makes me feel less alone. Keep it up. I'd like to give some constructive feedback though - try to avoid upspeak.
Interesting, never heard of that before! Appreciate the tip. 👍
On Agile development: There's no such thing as free lunch. Agile is useful for projects that in principle are unpredictable. It is not a remedy for poor leadership.
prism google “Cargo Cult Agile”
Perfectly stated 👏
Yeah worked at a company that replaced most of the engineering leadership with agile scrum zealots with the expectation that things would be faster. Development is slow: solution sprinkle some agile pixie dust on it and problem solved. 2yrs later everyone brought in to lead the agile charge were fired and the company churned about 30% of the devs, including awesome ones like me ;) The thing was to agile wasn't necessarily a clear solution to the problem, we released annually (accounting software), to a known consumer base with a large market share. We knew what features we wanted next, had a year to build them etc. Breaking things into sprints and trying to dream up how to turn the big features into small user stories and prioritize backlog etc etc was ultimately all unnecessary overhead because ultimately being agile wasn't required.
Right now we are converting to agile. I still don’t have specs. So I just start programming?
@@musclesmouse Oh no, don't use the agile garbage. It's worse than anything else. www.google.com/search?client=firefox-b-1-d&q=coconut+headphones+agile
Use this instead:
books.apple.com/us/book/how-to-write-great-software/id623560706
Not a programmer but a designer. I can relate to this! We spend most of our time "moving stuff to the lest or right" according to the team's personal taste, and often get frustrated because I cannot meet the deadline due to bad communication!
I'm a programmer with little knowledge of design, but it is enough to know that it is a waste of time to try to move things a bit around for hours because someone with less design knowledge and less realistic self image wants it that way. Especially when he says things like "the customers like it more that way". No, they don't. The majority likes it as this highly skilled and knowledging person who designed the theme we paid for, has already done it.
And on top, we don't have really have customers...
I was working on a functionality on a front end code and due to some backend issue my code was not working as intended , i had communicated that my code is correct and i think the issue is somewhere else , but the managers and leadership kept on nagging me to get it up and running asap ! Got 20-30 diffetent calls from different managers and leads , if its done or not ! It was one of the most frustrating thing i have worked on. Later when the back end issue was solved my code worked without a problem.
I like how you say different managers and leads. Have you noticed how much unnecessary people are there in typical software company? The best thing is, they don't have a clue about actual work because they never worked as devs but they are "leading" dev teams xD
How well said!!! You are right in all your points ! Now you must give some advice on how to send this video to my project manager
I have a understanding CEO, it is a small company. But he also programs, so he knows how hard it can be sometimes.
Agree.. most companies I worked for do give you time to research.. and be creative.. one product I designed for a company ended up making em millions even tho they never asked for it.. I just built it and theh loved it. But like I commented on before.. you can blurt something out in a meeting at any time.. be forceful and confident and dont care what anyone thinks.. offer to do something like "ill sketch something out and send it to everyone:.. making the assumption that everyone wants/needs to see what you are sending.. then they start talking about it..
I prefer having a technically knowledgeable manager so that he can understand the intricacies of software development.
However, the downside is that if the manager's skills are outdated, he might become a detriment to the project by forcing design decisions that although work, introduce technical debt, because the design, for example, becomes unscalable.
I've had heated debates about design decisions in the past because a "technical" manager thought his perspective was the best, but he didnt appear to understand entity relationships and OO design very well.
Also, I find that many engineers don't understand how to analyze requirements, which includes expressing the multiplicity of relationships -- e.g, 1 to 1, 1 to many, many to many, 0..1 to many, etc. If a design says that 2 entities must coexist (1 to 1), then the software MUST ensure that that relationship does not become broken. If the entities are persistent, then one can use a proper SQL database with transactions to preserve all relationships. If we delete one of the entities, we must delete the other, and vice-versa.
With database transactions, the database will ensure that all changes occur or none occur. We don't want to have a situation where a relationship becomes broken, which causes the software to fail in peculiar ways.
The ideal manager has a technical background and either his skills are current and he can make good decisions based on current practice that his equally educated team can support wholeheartedly, OR he's a manager that has the wisdom to step aside and defer to his engineering team to produce a robust design for the greater good of the project as opposed to a design that satisfies his fragile ego.
This is a really valuable contribution to the conversation, thanks for sharing. When technologists become managers they must decide that though they have a frame of reference, their subordinates doing the work know what’s best. And they need to let them make some of the same mistakes they did and learn. The only alternative is a technical micromanager and these are some of the most overbearing people to work with.
Thanks for sharing! Those are good points. I agree 100%
Very very helpful insight into understanding how developers work and how to work with them
Had a boss that didn't feel the developers needed to know the big picture of what they were building. Like treating it like an assembly line building parts or some government defense job. He then wondered why nothing worked as expected. Many many years later when the company dissolved he finally understood.
Ouch. Yeah sometimes we all learn the hard way 😕
In a wolf-pack, the lead wolf is always in the back, while the older, slower - but more experienced wolf - is always in the front, leading the pace. Hehe, not sure if this is transferrable to IT, but that's how wolf packs go...
Thanks, Great points Jayme!
More support! keep it up, slowly but surely you will reach more people.
Thank you. ✌️
This is such a problem in general in IT I have had some problems aswell with management naging about my project progress.
So rest assure, its a gap what seems between what they know about IT or care to know or be told about.
Yes software development leadership has a big gap in training and education in our industry currently. I spend a significant amount of time on projects earning trust with management and educating them to try and help the working conditions be more conducive to knowledge work in a highly complex problem domain. I talked about this in many of my videos, an older one “Creative Software Development: Explosive Growth By Letting Go” gets a bit rambly at times (one of my first videos) but there are some good nuggets in there: ruclips.net/video/e48KPylwaB4/видео.html
@@HealthyDev I love what you do btw, it is so nessary to close this gap between leadership and IT personal.
At the end of the day it will also boost efficiënte.
I also want to take your advice to heart in your video's in general, as I notice it is really important in the IT workfield.
Thank you for sharing your expertise and work experience.
It's important for companies to set up good incentive structures and transparency and lead by example. Devs may be given lots of time to do non-coding activity, think about the product, or experiment with designs. But at a lot of companies, non-coding is a black box, or product decisions are not transparent, or ownership/control gets more recognition than effective collaboration.
As a result, devs may feel territorial. They see crowding out at the decision-making levels. They fear early-stage collaboration because of ownership optics. The dev policies to ensure quality are limited to code review or test coverage. Because devs are not made to share their implementation strategy at a higher level or how it's evolving, and have political fears, they go into their silo until their feature is done. Spaghetti code and spaghetti products result.
I am not sure how to change this at companies where it's a problem. I can't blame devs for recognizing the incentive structure, and I don't think people at the top will care to change a system where they emerged as the winners.
You’re very insightful. Companies can reward cross functional teams instead of individuals. Some already do this, but it’s rare. There’s fear that people won’t be motivated if they aren’t pitted against each other. While that may be true in some industries, it’s completely baseless for an activity like software development which is collaborative knowledge work!
@@HealthyDev Thanks. I've tried to push these sorts of changes with not a lot of success. I wish I knew more effective tactics, or perhaps just how to recognize when to throw in the towel.
It’s a hard skill to learn, but not impossible. I encourage people with some of my other videos to learn consulting skills. It may not seem as impactful as better technical knowledge, but at a certain point in our career (at least in my experience), it is.
Been enjoying your videos, a lot of handy tips. I've got a question of a sort of a-typical problem:
We've got a bunch of developers in Asia that actually like to be told what to work on, they do not like to take ownership of the Sprint Backlog. They're extremely used to a working and general culture where "following orders" was the norm and now they expect this type of leadership. What are some tips we can use to solve this?
You need an architect level technical resource who will hand practically pre-coded UML diagrams, sequence diagrams, and acceptance criteria to them. Or put in place a center of excellence for learning so these developers can improve their ability to deduce and own the work. Or hire more expensive developers with more skill.
Something tells me that you are describing the company I work for... where devs are seen as typing resources.
This is interesting, managers probably should care more about the Scrum Burning chart, what i experienced first hand, that managers put lots and lots storie into backlog and demand to do majority of them in 2 Weeks iteration it was really messed up, only when i as consultant came in and started to protect team from such situation thing got better.
You have made some great points. I've been going through your back catalogue as I want to get better in my role and make sure we're implementing scrum correctly.
Just wanted to note: sharing this with any management team might be hard when the title is "Why Do Managers Treat Programmers Like Children?". So although it's a nice idea to want to share this with your managers, it seems impractical given the click bait title that might make managers feel personally attacked.
Today's developers are tomorrow's managers. Feel free to take some of the points from this video and present them in other ways to management as you see fit. I want to see us all be healthier developers out there!
@@HealthyDev It's a good goal, for sure.
I'm actually a CTO, trying to make sure my team has the best chance to succeed.
Nah, devs arent expensive, its just that were basically halftime at the company, the other half gets wasted by management and with no code being written. Worse if they dont get code and everything turns into a ball of mud 'cos of their requirements and everythine slows down further.
Exactly - I love programming while Agile Scrum makes me hate my life. Then they have this militant style like HR would. Worst of all, they put non-programmers in charge.
#9 is my favorite for me. When the developers loose sight of what the code they are writing is good for, they can't provide creative ideas on hw to improve the product.
Hits the nail on the head. Exactly list all the problems I seen. But to convince mangers and companies of this message is like deep sea diving with nothing but a speedo. Fat chance management will listen.
Absolutely. Today’s developers are tomorrow’s managers :)
I have been through having to give daily status reports directly to my manager. I had been working for the company for about 4 months at this time. It's just as you said. Didn't even feel like he was reading them and sometimes he wouldn't even respond. Felt more like an authority move. Very insulting for sure, and only hindered progress.
"Changing scope has costs associated with it." Yeah, I had a job where scope was changing almost daily due to ban planning and things not being thought out. Then management would turn around and ask why things were taking so long and why we couldn't meet our targets. Yeah, never again.
"Tired programmers make rash decisions." Yes! Been there done that. LOL :-)
I am getting more and more frustrated with this "Capitalistic" software development where quantity is more important than quality. Over the past year I've had several issues with hardware that I bought and it didn't work as it should. Most recently I bought a GoPro Hero 9 which has some dead pixels (basically unusable) and now have to wait for them to release a firmware update which hopefully will fix the issue. I guess the underlying problem to all of this is greed, everyone just wants to make quick money (The ones that already have enough want even more)...
Sound like there are a lot of pointy haired bosses like in Dilbert out there or it's an office space environment both which seem to be bad for the creativity and making sure the quality is in whatever the developers send out to be the final product
.
Thank you. This is actually very helpful feedback to me right now.
You're very welcome!
The best video on RUclips regarding management of sw development!
Scrum is a scam. It looks like its not meant to make a project more successfull but to mess up everything.
This issue is due to the economics of the business. Developers need to study the top of company, and understand the nature of the business before joining. There are many "malignant" or even "predatory" dev shops that's literally make money by squeezing labor from a small dev team. These are usually small to medium sized business that typically sell software to the government, and love to hire many cheap junior devs. They place an Agile management which is to simply used for analytics about dev performance... So in my opinion this is a labor issue or even political.. We developers need to form a UNION!!!
15:14 Well said. Yes, after a while people get a very narrow focus on the local results while it feels more and more like a rat race. And Sprint reviews alone are not necessarily helping much. It's much better to stay in touch with the testers, and have a look at the whole project's output from their point of view, at least from time to time.
It would be nice to see a video from the opposite perspective, to help programmers understand why management asks for updates, why timelines exist, etc. A lot of the issues I think that stem between management and production (whether that's software or widgets) is a lack of understanding.
Thanks for the feedback Luke. I plan to do some of this, but the way most projects are managed today doesn’t match the characteristics of software. I’ve talked about this in prior videos but I’ll be sure to revisit it.
Appreciate your feedback. I made a video called “Healing the rift between programmers and managers” so I want to see this happening!
I just find much of the process advice out there caters to managers and not those doing the work.
Usually the problem with middle managers is that if they have no clue about software engineering and therefore they are unable to effectively negotiate deadlines with their superiors. With the advent of scrum, middle managers mutate into micromanagers and they rarely negotiate with the Product managers as they are technically unable to do so
This was really a well done video thank you
Upper management at my company wants daily status updates for who they view as underperformers. There's generally no positive feedback - there's either silence or negative feedback about minor things. This makes us feel like management does not trust us and only uses these status updates as a way to nitpick someone's work.
There's no incentive to try new things or take on work that has any risk of not being completed by the estimated date. It will be nitpicked during these status updates. This hurts the company in the long run and is causing me to actively look for a new job.
Bingo. Sorry you're going through this, in my opinion your evaluation of the situation is right on. If all management does is actively look for problems that's all they'll see. I talked about that in another video that might be relatable to your scenario, "Is It Safe To Make Mistakes On Your Software Project?": ruclips.net/video/-dhLuNcMUIo/видео.html
You feel like the developer dad I never had !
Just a question, what’s acceptable speed to get things done? Because if I get 10x the work done no place would pay 10x the pay. So what if people are just being lazy? And I’m not talking once per sprint I mean consistently?
Point 7 I would just say be careful about what features and ideas you suggest if you're a developer. For starters no one is going to give you a 100k bonus because you 'thought up a great feature'. If you pitch a generally good idea to the product owner they're probably say something like 'Yes we've been considering something like that for a while but we've not quite there with it yet' even though they're actually trying to work out how they're going to pitch it to the higher ups to make it look like they had that idea all along. In all seriousness there is always a risk you're just going to annoy the product owner because it can look like you're trying to step on their toes or undermine their authority. You're ether coming up with amazing ideas and making them look inferior or they're just having to work out how they're going to diplomatically shoot you down all the time. Generally speaking mastering the lane you're assigned to and will be ultimately evaluated on is better than trying to cut into someone else's.
I’d say that’s true in command and control corporate cultures. In more cross functional teams the whole point is to minimize the lanes. Meaning you still have specializations from a division of labor standpoint but there’s team ownership (and rewards) so people can contribute ideas outside of what might traditionally be a lane. You of course have to budget differently and you’re changing people’s motivation from individual to product - but you’re getting higher engagement and creativity - which is where the profit generating theories of value come from. These are slow moving changes in our industry, but they are having some success at companies willing to try them because they do have aspects that gel better with the fact that software development is collaborative knowledge work and not manufacturing.
@@HealthyDev Do you think this is getting more or less common? I know Agile is newish but as the field grows, I see more and more pressure to specialize. The harder it is to find a skillset, the less management wants people with it spending time on other things.
In that regard I think being a junior dev is often more fun than senior, if the company gives you room to explore instead of pigeonholing you at least.
@@qubitblogonmedium6160 I'm not sure I have an opinion on whether it's getting more or less common. There is pressure to specialize because of the complexity of the field - but there are also leaders and managers who recognize potential dangers in it and setup their culture to accommodate accordingly. The future is still wide open there...
Good Video!
I'm also not super convinced of Scrum.
I agree with the contents, as it depicts a rather sad picture of software / contents development today. I worked on both ends, so I believe I can safely say the misunderstanding / ignorance / idiocy are on the rise - possibly a sign of modern era, which I'd put as a 'quantity over quality' approach. Phrase 'just make it work, we'll fix it later' still haunts my memories.
My only comment here - I think I'd change 'leaders' to 'managers' in the title - there are very few leaders, but 'waaaaay' (say it loud with pathos) too many managers.
In other words, every other idiot can be a manager (and 'waaaaay' too many are), but ('waaaaay' too) few leaders are actually managers.
Working as a mechanical engineer.... it's the same for us, too. When you have to explain for the 20th time why a 4-week long environmental test cannot be done within one week, it is soul-crushing. xD
I am a php programmer going forward for web app development throught this route with no cs degree. Wanna be a software developer in near future. But nowdays i am loosing motivation because the expectation of people are so high, i'm having a hard time. Somerime i feel like a fraud
It’s common for us to feel like that, I did a video on imposter syndrome you can watch that might help.
I’m of the opinion that you’re absolutely NOT a fraud. When I feel uncomfortable with something it means I’m growing. If you can find a way to accept that feeling as a necessary emotion for growth, you’re actually ahead of many developers who might think they’re further along than they are.
Don’t give up. You can do this. I have to fight with this feeling every time I learn something new. If you learn to embrace and master this part of the job, you’ll have a long career and never get stuck working on outdated technology!
Healthy Software Developer thank you for the sugesstion, can i know which tech stack are you working with. . Net, java, php, node etc?
I’m not coding currently, I’m actually in the market for a new consulting contract, or perhaps a product management or coaching gig.
My favorite stacks are ruby and .net, but I’ve also done quite a bit of java over the years. Have only messed with node on the side. I like swift for iOS and pretty much all the BI/data manipulation technologies. I also like working with AWS and Azure.
Nice Set!! What’s your kit? What kind of music do you play?
How about a discussion on how playing music might gave helped in your coding career?
Hey Jim it's a 1971 square badge Gretsch bop kit. I write stuff usually from singing and acoustic guitar, then add whatever it needs. Sometimes just guitars, sometimes drums/bass/synth, it all depends. I just do it for fun.
10:48 - The holy trinity (best solution, done in the least time and, importantly, most maintainable).
I didn't watch, but would answer the title from a social psychology perspective. (I like to head straight to the root.) ... *It's probably a jocks-vs-nerds thing.*
Funny-sad anecdote: I was in a meeting about career development at a company, with people of various ranks/departments present, and the guy did a Powerpoint presentation where he explained two major career paths: "professional" and "managerial". I found it disturbing that I was the only one grinning and hardly able to suppress a snicker. Was I witnessing the widespread absurdity of the business world meeting utterly jaded people who had normalized the cynicism of it? Or were people afraid of losing their job and trying to practice sucking up by going along with the BS? - (I didn't work there for much longer. ... And it didn't get any better. ... Now I'm burned out.)
The cultiness annoys me to no end. Until we can accept that a fashion loving extrovert woman can code as well as a stereotypical geek guy D&I will be limited to tokenism and innovation will be limited to group think.
Business Analysts can really help alleviate a lot of this.
Hi, I love your videos. Could you make another one about the age discrimination in the industry which i think is pretty common? Thanks
Great suggestion. I may talk about this more. I did talk about it some in the video "New Framework Disease (NFD) in Software Development": ruclips.net/video/NCEABmfE2YQ/видео.html
Our VP of software engineering used to say all the devs did nothing but drink coffee all day even though we brought every project in on time. Our CIO knew better. VP is no longer there lol.
Can’t agree more. Daily standup meeting is bullsh*t. It produces nothing but insulting.
My favorite was a TSA who was trying to do testing and the PM was calling once an hour to see if they where done, he finally moved to a different meeting room and would not tell anyone where he was, he got it done after that...
As a test engineer going around to SW companies, I agree with all above
Nice round badge kit btw. I have the same one. Insane kick drum sound for its size.
Nice! It’s the first year square badge. The last year they used the same shells as the round badges!
@@HealthyDev My mistake. I bet it sounds great
@@DIYGuitarMods oh no worries! I just thought you might find that interesting. I lucked out. Having a round badge would be even better!
It's a trust issue mixed with there lack of knowledge on software development and project management.
Yep. Some of the best developers I’ve worked with spend more time educating management than writing code. It makes the job better for everyone else, but it takes incredible patience
@@HealthyDev welcome to my world. I have to spend weeks debating why code reviews are good. Management want me to re-write everyone's code all the time because they think code reviews slow development down. Lol. But no problem with 2 weeks of rewrite.
Make me wonder if this is why we get the unfinished buggy video games these days.
It's a very interesting topic told from perspective of a programmer. I wonder if you'd like to do something similar but from manager's perspective. I would love to have a chat or at least exchange some ideas. I was a programmer for 15+ years (but coded almost whole my life) and now I'm a manger for 5+ years.
Full transparency I'm focused more on helping the "line workers" than management in this channel - but I do understand it's a two way street. One of the other videos of mine you may have some feedback on (or relate to more?) is "Healing the Rift Between Programmers and Managers": ruclips.net/video/_TlQb8MKCNo/видео.html
quieting shitty corporate job now where they treat like a child, asking for updates every hour and sitting on our heads all the time pressurize like hell..i cant do programming with this constant pressure.. will drive tractor on the field and do farming in open in positive healthy environment :)
Let's be honest, though. Some developers could do a better job of communicating their status, pushing their code, commenting in their tickets. I don't think managers in general WANT to nag. They do it because they feel otherwise helplessly unaware of where everyone is at.
While this is true (human behavior runs a wide gamut) as I talk about in my video on daily standup meetings we have technology for management to know what’s going on now. They’re often too impatient and want to waste time asking follow up questions about status they already see in Jira or another tool thinking somehow they know how to optimize work better than the people doing it! If a manager can’t trust their employees, they shouldn’t hire them...
I'm one of those developers who is not mature enough to come up front when a task is taking longer. Mostly because they'll grill me for it. Or they'll ask for overtime since it's "my problem"
I'm in such a position where I'm being pressured. I'm the only developer building an ERP/CRM/E-commerce solution. 'Boy have I learned a lot about my limitations. But I have to produce so that we can make our customers happy so that they pay us.
To put this succinctly, success emerges when from trust between managers and engineers. Without trust, everyone becomes miserable and failure is likely. Now... how to get that trust... hint: you won't find the answer in any book about algorithms or frameworks.
Well, PM is always breathing down my neck every 2 hours asking about progress. It's so frustrating
7:59 - *and* to top off it being more complicated, how are we supposed to know that now this is going to change mid-stream? Management will get themselves tied up in knots if they don’t understand this. i.e. Now the system is _so over complicated_ thanks to the scatterbrain, it takes longer to make a simple change and now we _hope_ that they don’t change the scope while we’re spending that extra time to get the request done. Ideally
I am right in the progress of leaving project because of this :)
Good valid points.
Wow I'm really glad none of the places I've worked at have been like this
On the being agile part:
We have one very innocent sounding change which comes up a lot and causes us a lot of headaches.
On one of our internal systems we have a lot of data capture forms, these include a lot of dropdowns.
We ask many times when adding these that they will only ever need to select ONE option and they tell us without a doubt it will only ever be one.
Later down the line many of these change to be multi-selects.
They wouldn't even tell us how they want this to be reflected in the reporting or document generation 😂
I'm sure when I said if they need to select ONE option or MANY options all programmers will instantly click what type of issues arise here xD
Oh, that's gotta be flipping annoying. Either you gotta go back and refactor your data model each time, or accept "preemptive denormalization" by designing it to accommodate all the changes anyone might ever want upfront, or (most likely, I'm guessing) completely sacrifice type-checking things and having a consistent data model at all. (Maybe just throw it all in MongoDB and hope it becomes someone else's problem before you have to face the inevitable consequences?)
Its amazing how some of the biggest projects in the history of mankind such as "The Manhattan project" did not use Scrum, Agile or any other management methods
Thats because it needed 0 bugs :) really 0 bugs... that was the atomic bomb... if one very small thing didn't work than everything else is doomed.. in software agile you can many many small bugs
it helps immensely if you have one big goal that does not change. you got essentially an unlimited budget and manpower. that is very different to a software project.
@@samsarasap4911 True, the methodology implies that the final result is so agile that it produces not only all the desire effects but also some bugs( as a bonus...)
@@qdeqdeqdeqde Great observation but the question still remains: if a software development methodology produces errors in the final product than its simply not good enough, so why do we need all these consultants and Agile/Scrum experts to tell an organization how to do their job?
I actually prefer being asked for status frequently as opposed to being neglected for long periods of time because at least I know what is expected of me
If it weren't for the title it would be a great video to share with my manager.