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.
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.
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.
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!
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.
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! ru-vid.com/video/%D0%B2%D0%B8%D0%B4%D0%B5%D0%BE-EqjFFp36X4o.html
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!
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: ru-vid.com/video/%D0%B2%D0%B8%D0%B4%D0%B5%D0%BE-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.
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.
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.
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 🤣
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.
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
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 RU-vidr, 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 RU-vidr 🤭, 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. = )
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.
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.
"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.
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...
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.
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.
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.
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.
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!
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...
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
4 года назад
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)...
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?": ru-vid.com/video/%D0%B2%D0%B8%D0%B4%D0%B5%D0%BE--dhLuNcMUIo.html
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 .
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.
The best video on RU-vid 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.
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?)
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.
Great suggestion. I may talk about this more. I did talk about it some in the video "New Framework Disease (NFD) in Software Development": ru-vid.com/video/%D0%B2%D0%B8%D0%B4%D0%B5%D0%BE-NCEABmfE2YQ.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?
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.
The part about agile costs is flawed. Yes, IF one knew ALL the requirements up front then it would be easy and more efficient to build the software. However, it has been proven over decades that one NEVER knows all the requirements up front. The entire idea of agile programming takes that fact into account. In the end of the day, it is far more efficient overall to refactor, rebuild, etc. in a continuous looping spiral of change than it is to try to go waterfall and write all the requirements up front. Note: This doesn't totally apply when getting started with something that is brand new, like a brand new product or new architectural layer. There does need to be a chunk of something to build around and those initial chunks are best built by spending some time just thinking about the requirements and need for flexibility before diving in. It is also usually very beneficial to build that initial chunk at least twice, i.e. build once and then redo.
Hey Brad, thanks for the feedback. I think we actually agree. I provide more context in many of my videos about agile. A couple in particular where I address when having loose versus strict requirements make sense are “How to spot a fake agile team” and “can user stories make a software project late?”
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"
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.
Scheduling, project planning, is just a bunch of BS. It is a bunch idiots with wishful thinking and wishing for some certainty about some arbitrary dates. The bigger problem is these people think the developers only got the project to deal with. The reality is an endless stream of random unpredictable distractions, interruptions, fires to put out both from within work and heaven forbid something outside of work.
99% agreement - I watched a company who couldn’t get one month predicted accurately spend a full day of everyone’s time four times a year, guessing 3-6 months ahead. They didn’t even know what the customer would want in two months. It gave false senses of progress that fell apart and disheartened everyone. Again and again.
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.
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
I hate when they ask for status in theirs specific stupid format that consume significant time on my side when I would have gladly used that time to develop the solution.
The reason people hate micromanagement is because it implies that they wouldn't do something unless the supervisor prodded them to. So in a way it 'steals' your pride for achieving something.
2:27 I'm a game dev. We fell victim to this when we found an (in hindsight, very shitty) publisher. Constantly asking for weekly updates. "No no, just make a simple summary of what you're doing next". It's like: Listen, you fucking boomer, we're 4 people here. Making your fucking doc is taking 15 to 25% of our workload. And in a few months, you'll complain about us being a month late.
Programming is like cooking; there isn't a 'right' way, or more accurately, there's more than one 'right' way. However, there are most certainly many specific wrong ways...
I started my office from 12 noon n finish 9 pm n almost forgot how evening looks like how sunsets looks … I left that job n believe me software engineering developer is like Stockholm syndrome ..
Plural sight is a training website with more videos than anyone could watch if you like learning that way. If you prefer books, try searching Amazon if you haven’t already and sort by the highest review. I think agile web development with rails, even though it’s not a php book, is a good one to understand how to build websites in pieces. If you’re using more advanced front end frameworks like react or angular, it’s really important to have a strong grasp on html and css first (just my opinion). If you can find other students or hobbyists who are hacking on web apps built in php, you could try reaching out to them to see if you can try hacking on pieces of it to learn. Just be up front that you’re learning and try to not take any feedback about your code that’s critical personally. I never attended coding boot camps back when I started, but some people find these are really helpful. Most charge a fee, but sometimes companies will have free ones to raise awareness of their company or product. Going through tutorials in your stack of choice and getting to know the major features of that language or framework can help you build a nice demo or sample project that can help you get your foot in the door at an entry level job if you show and explain what you built during an interview.
I also have no CS degree and i am 100% with Jayme on this, I've got roughly 350 hours spent on pluralsight and they easily have the best collection of resources. Udemy has a few gems here and there as well depending on what your after. I was able to get up to speed with my full .net team with nothing more than a bit of web dev knowledge in about 6 months. Resources only go so far though, best practice would be to build something, regardless of how small it is out of the knowledge you just learned to really get the feel for it, The trick is that of the 8 languages I have learned so far, there is always an IDE or Google to help you remember syntax... Knowing that something can be done and how to do it is much more valuable and far as i can tell, relatively unteachable. I am about 2 and a half years into it professionally at this point and I have no problem keeping up with the senior devs... well.. unless they start bringing up the archaic shit.
Leaders do not care. They think that programmers are shit. I have been treated like shit all the time. And I don't know anything other than programming. Please suggest some alternative career! Thanks!
Sorry you’ve had such a hard time. If you really want to get out, one thing to consider is what aspects of development day to day got you energized - and which instead drain you of energy. Look for career options where you may get to spend more time doing things that don’t sap your willpower. Hope you find your way. 🙏
Is this video supposed to accommodate every person on the face of the earth? Sorry that’s just not possible. I still contend it’s good for you. If I had to say “if it’s possible” in front of every statement it would be ridiculous to watch.
You have clearly articulated the sad reality that has become normal life for nearly every software engineer working for a well-funded company, so let me ask; who are you addressing with this video? Chances are that any manager that watches this, even if they are guilty in the 1st degree of every point you've outlined, will not be self-aware enough to understand that they perpetuate their poor leadership through every action they take.
I often approach the same issue from multiple angles, but I definitely have areas to improve. What was one of the areas you felt was redundant? Thanks for the feedback!
Sure, but it usually takes a better programmer to recognize the cause.
2 года назад
Good advices in general, but from the point of view that the CEO is someone without experience or understanding of the market, software development or the product. I've seen way more developers being unaware of all of this than CEO, yet the prejudice is on the other directions because of the visibility of the position.
I don't find most developers believe they know more about the market or product. I think we believe we know more about the nature of the software engineering craft, and how it should be done to produce a product. Not sure if that helps.
@Peter Mortensen If Agile is not practiced in the way theory commands is mostly because the theory does not work in practice And if a theory cannot be applied properly in practical situations, it is not a good theory.
Because most programmers can't explain how to make toast in a straight forward manner so they end up wasting everyone's time on tangents that don't matter. I've been on both sides of the aisle. For leaders its important to set expectations on WHAT kind of information they want instead of showing up clueless and expecting the programmer to enlighten them. For the Programmer you need to focus on what the management objectives and be prepared to interact with them in that way(i.e Faster, cheaper, more reliable, better qa, more reusable, schedule, partnerships etc) when they ask you a question. When you're a manager everyone's problems become your problems. Problems from above and problems from below. And if you didn't even rise to that role from the trenches then you're clueless regarding the struggles programmer go through. When you're a programmer you're always under the gun SO it to your benefit to develop programming patterns(boiler plate code if you will) to knock out POCs and when you're asked about estimates you can do so from a perspective where you're POC components have already been proven and performance measure instead of responding duh idk. It depends. So a good team requires good programmers and managers, all of them have to develop or have practical leadership skills and be proactive. No room for timidity or shyness. Learn your shyt and get to work. Also, status should be requested at least once a week by the project manager but the tech lead needs to be on top of all the tasks and have an idea what's involved in each and how long they should take. Sure, nobody works at %100 but you can't also hide and hope nobody notices until time has been wasted. And Architects or Tech leads need to create the scaffolding for software with a known pattern so that adding or customizing features become more plug and play instead of unique rewrite for each new feature. And this goes for all the support teams like testing , CICD etc. This is what happens in a professional kitchen so why would you think it'd be any different on a programming team?
Disagree. As a programmer I love giving my statuses at least once every day. How is that putting preassure on anyone? If 8 hours of coding isnt enough for someone to produce minimal amount of work that could be summerised on a stand up then the management would be right questioning their productivity.
Part of it depends on how many problems you need to solve in a single unit of work, and how deeply you'll need to analyze the alternatives. Needing to sync with others at a fixed rate often puts a hard cap on how deeply you can research an approach before committing to a solution, which can lead to very unfortunate effects when you're doing things like trying to selecting an abstraction which have knock-on effects. One way around this is to break out research as a separate unit of work, but I've never found that really natural; personally I find the only way to research the best way to do a task in sufficient depth is to try to do it and see what works. I might write several almost-complete implementations with different approaches before figuring out which one is optimal. In any case, after I have finished I usually have working code, so the "research" and "implementation" tickets don't have a hard separation to them.
@@MrNerdHair Thanks for the reply. Seems like I wasn't aware that researching solutions could be a significant part of developer's worktime. At the company where I work, we are managed up to a single design choice (yep we always have ready solution designs in our user stories). Even the development lifecycle is a pseudo-agile lie - all user stories are estimated by managers and accepted by the "business" before development can start. We're building enterprise software with a very structured framework so I guess this makes as especially suitable for the high level of control. If I may ask, how often do you have to make research before starting to code?
@@zjankowski Fairly often. Not all the time, but especially when greenfielding stuff. In general though, it happens any time the task breakdown didn't go deep enough. If you've got management or architectural support that's technically competent enough to perform accurate, complete task breakdowns before work starts, that's wonderful! (That hasn't really been my experience in general.)
And you wonder why landing a spacecraft in the ocean is such a big deal today, even though it was routine 50 years ago. We are more concerned about feelings and passion instead of completing a project. Rude awakening folks, customers really don't care about your feelings, they want a product or service, how you get it done is on you. Stop the whining.
So you can’t build successful products and also care about the wellbeing of your employees? If you think being treated fairly is whining, why are you watching this channel?
@@HealthyDev Hate to say it but its' true, right? Ok, so when you go and buy a pizza, do you stop and ask every person working the diner how well they are treated and how much they are paid? Everybody want's a $15 minimum wage, but when it's time to pay the babysitter she gets $20 for five hours of work... see what I mean?
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.
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.
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
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!!!
