Asking a 1,000 Developers What They HATE About Software
We asked 1,000 software developers what they hate about software, and in this video I show a collection of their responses. So what are the bad things about software engineering? What are the downsides of a software developer career? What are the bad things about software engineering?
In this episode Dave Farley reports back on what software developers think of their profession, their working conditions, the technologies that they use and the nature of creating new things with software.
-
⭐ PATREON:
Join the Continuous Delivery community and access extra perks & content!
JOIN HERE for as little as £2 ➡️ bit.ly/ContinuousDeliveryPatreon
-
🖇 LINKS:
🔗 “Unix Design Philosophy”: ➡️ en.wikipedia.org/wiki/Unix_ph...
🔗
“Microservices Probably Aren’t What you Think they are”, Dave Farley: ➡️ threadreaderapp.com/thread/16...
-
👕 T-SHIRTS:
A fan of the T-shirts I wear in my videos? Grab your own, at reduced prices EXCLUSIVE TO CONTINUOUS DELIVERY FOLLOWERS! Get money off the already reasonably priced t-shirts!
🔗 Check out their collection HERE: bit.ly/3vTkWy3
🚨 DON'T FORGET TO USE THIS DISCOUNT CODE: ContinuousDelivery
-
BOOKS:
📖 Dave’s NEW BOOK "Modern Software Engineering" is available as paperback, or kindle here ➡️ amzn.to/3DwdwT3
and NOW as an AUDIOBOOK available on iTunes, Amazon and Audible.
📖 The original, award-winning "Continuous Delivery" book by Dave Farley and Jez Humble ➡️ amzn.to/2WxRYmx
📖 "Continuous Delivery Pipelines" by Dave Farley
Paperback ➡️ amzn.to/3gIULlA
ebook version ➡️ leanpub.com/cd-pipelines
NOTE: If you click on one of the Amazon Affiliate links and buy the book, Continuous Delivery Ltd. will get a small fee for the recommendation with NO increase in cost to you.
-
⭐ ShiftSync Community | Tricentis
Tricentis is expanding its learning communities and just launched a new community -ShiftSync. It is a community for anyone interested in all aspects of quality engineering, from left to right across the software development spectrum. The platform features engaging content, user forums, and industry expert contributions. If you are a developer, tester or DevOps specialist, who wants to build secure, robust end-products and set up high-functioning development teams, check the ShiftSync community ➡️ bit.ly/ShiftSyncCD
-
CHANNEL SPONSORS:
Equal Experts is a product software development consultancy with a network of over 1,000 experienced technology consultants globally. They increase the pace of innovation by using modern software engineering practices that embrace Continuous Delivery, Security, and Operability from the outset ➡️ bit.ly/3ASy8n0
Sleuth is the #1 most accurate and actionable DORA metrics tracker for improving engineering efficiency. Sleuth models your entire development cycle by integrating with the tools you already invest in. You get a full and accurate view of your deployments, see where true bottlenecks lie, and keep your team’s unique processes and workflows. With accurate data, Sleuth surfaces insights that your engineers can act on to improve - with real impact. ➡️ www.sleuth.io/
IcePanel is a collaborative diagramming tool to align software engineering and product teams on technical decisions across the business. Create an interactive map of your software systems and give your teams full context about how things work now and in the future. ➡️ u.icepanel.io/1f7b2db3
Tricentis is an AI-powered platform helping you to deliver digital innovation faster and with less risk by providing a fundamentally better approach to test automation. Discover the power of continuous testing with Tricentis. ➡️ bit.ly/TricentisCD
TransFICC provides low-latency connectivity, automated trading workflows and e-trading systems for Fixed Income and Derivatives. TransFICC resolves the issue of market fragmentation by providing banks and asset managers with a unified low-latency, robust and scalable API, which provides connectivity to multiple trading venues while supporting numerous complex workflows across asset classes such as Rates and Credit Bonds, Repos, Mortgage-Backed Securities and Interest Rate Swaps ➡️ transficc.com
If you enjoy discussing ideas, issues, problems and even frustrations! with fellow IT guys, join us on my CD Discord via 🗣 bit.ly/ContinuousDeliveryPatreon and see lots of other membership benefits, exclusive content and competitions.
As opposed to really listening to the people doing the actual work, hiring external consultants to come in tell you where you're going wrong, introduce some scaled Agile nonsense, shoehorn existing managers into roles they don't understand, then bugger off...
I hate that people treat abstractions as "free". I hate it when explicit coupling is replaced with implicit coupling then call it "fixed". Actually, it's worse now.
At the end they're never free. It always adds overhead, either at the compilation stage or at run time. Personally I prefer compilation overheads
You're not dogmatic, Dave. You're just telling us the stories about how you got those bruises and why you'll "never do that again!"
in my current job what I hate the most are : lack of documentation or documentation that is disseminated on multiple servers, not connected, copy paste of the same code over and over, 1 occurrence per customer each time with a slight modification that cannot be added the the previous code, and most of all: specifications that change during the acceptance test.
agree with lack of doc, sometime the code for a feature spread across files, heaven if they are connected by "import" so I can jump easily, unfortunately, they are not. I spent hours just to make sure small changes i made are safe to be deployed after I read the rest of code. Tasks something like these several times give me some anxiety.
Most languages have copy paste built-in. It's called libraries and linkers.
Get used to it because this has always been a problem and is always going to be. Developers hate writing documentation and managers hate paying for it.
I strongly dislike working with developers with an extremely high tolerance for risk and inefficiency.
I love your comment about Jira. Beside developer/devops I am also Jira administrator for our 1k employee company (or to be precise all Atlassian apps administrator). I believe my most important task there, one could say crusade even, is to SIMPLIFY as much as possible -- workflows, custom fields and other Jira constructs. The thing is, often project/team leaders and/or PMs decide and design Jira project/workflow settings. And you wouldn't believe how many times I have to explain that something is too complicated, tiresome for users and/or just needless. That's what GOOD Jira administrator should do -- defend user from overwhelming management bureaucracy. Sometimes they agree, sometimes they come back after some time saying "you were right" but... in most cases I talk to a brick wall ("we are used to work like that", "you do not work with customer, you don't know realities"). So, remember, guys, that after every badly configured Jira project, there is some person/s who wanted it to be like that. Do not evaluate the tool. Because Jira is just a tool -- nothing more, nothing less. Also, remember that Jira has pretty great REST API, accessible for EVERY user (because web UI uses it), so you could automate almost everything! I've seen many teams writing their own scripts or even whole GUI apps, accelerating their tasks. :)
We're only at about 150 people in Jira but even at that scale the answer is that delivery teams don't get to create their own Jira projects. We have 3 admins who create any new projects and have a base template/standard workflows that every project has. If people want customizations on top of that they can have them, but our admins get the chance to ask why and what problem it solves.
I partly agree with your defence of the tool but I still criticise the design decision and culture of JIRA which encourages chaos and delegates the power to create chaos much too widely.
@@gilgamecha agreed, but still this is evaluating a tool. Look, cars are also designed to "encourage chaos" and even kill people. But we don't see deadly road havoc, do we? And even if, it's not on daily basis and in most cases (often?) caused by drivers, not cars themselves. And one could go on and on with such examples.
I hate the pace which software is expected to be delivered without incorporating a lot of time to learn and experiment. Most times we don't know the best way to do something. We just figure out SOME way and we have to move on bc the amount is so much. There isnt time to reflect or refactor very often.
I've just told the team I am temporarily looking after to ditch their k8s cluster. They're data engineers primarily, don't have the skills administer the cluster well, and they're writing a batch processing application....they were spending more time faffing with the cluster rather than solving the customer's problem.
I can completely understand this problem. I have seen some complicated and slower microservices stuff to handle things where it made no sense at all. Like basic HPC calculation stuff.
How can you do data stuff without ArgoCD on k8s? Not possible.
I really like the idea that Jira is a "bureaucracy exposer". I'll have to remember that when I explain to newcomers why our Jira is so weird.
You use home grown jira plugins too 😂 it is a nigthmare with just the marked plugins
@@Flamechr Fortunately not - I'm an application security guy and that frankly would give me even more nightmares.
Jira is garbage. Its destroyed tech work entirely.
We recently moved to using ADO and the first tour of the product showcased how awesome it is for product owners and scrum masters. I was just blown away by how much the tour was aimed far more at management then the actual developers. There are so many ways that it could be a better development aid, but it just isn't meant for that. It's a tool for bureaucracy, 100%.
I used to be only developer, but then started a new company and now I understand why something alike Jira is NEEDED. You cannot ever justify anything to your investors without it.
Slow dev environments. We should code at the speed of thought.
Eww. That would be messy.
Why?
@@ChaosturnMusic because the brain isn't linear and thought patterns are unorganized. The act of coding is the process of organizing thought into something tangible. Also, people mostly think about food and sex. That might be confusing for the mind reading computer.
It's called vi. Sounds like vee eye. :)
Jira exposes bureaucracy == 100%. And by the way Dave, I love hearing how you present your positions. It makes me want to explain my positions in a way that is calm, well thought out, and non-defensive. I think, and hope, some of that comes with years of experience and realizing all the silly things we can get attached to and argue about are not as important as we think they are.
8:33 My code using libraries vs. my code shoehorned into a framework. Great insight!
I was fortunate to join my current project early and I managed to get a load of linters, code formatters, static code analysers and test tools in place before a lot of code was written. Doing this takes care of so much needless code reviewing about style and stops simple bugs before they reach the codebase.
the pull request idea is gatekeeping, i.e. when you haven't got a proper automated test suite with reasonable coverage or tests at all.
Just a small comment: I'm a programming teacher, so I don't suffer these market obfuscations, but I'm very much interested in what works, what doesn't work, and the conditions for improvements, so these kinds of surveys are very important for me: thanks Dave! Keep the good work up! And thanks a lot, all commenters on Dave's Xweet!
Fun vid. Poor/lack of documentation and/or an API that doesn't work as documented. There is no worse feeling than wasting time.
Spaces versus tabs. The hypocrisy of it. Ignore good design and architecture but make sure your code all lines up. Ugh! Gnats versus camels.
Editorconfig and CTRL+K+E. Problem solved. Now you're freed up to discuss the business domain.
The problem with frameworks is longevity of support. .NET is a good example, the transition from software built on .NET Framework costs.
I've seen "waterfall" work, and it's under medical appliances. The process there really have to be rigid in order to conform to medical standards. Can't really do "fail fast" on something that controls your heartbeat.
Develops the code for the pacemaker Passes QA tests Demo with living patient He dies because the initial requirement was wrong They send the feedback to fix it
Very insightful. Thank you! Could you make a video about hiring practices in IT industry, please? Job requirements (laundry list of requirements), interview process, ghosting by recruiters and companies etc
Try this: kzhead.info/sun/ZaWfm52DjXedo30/bejne.html and this kzhead.info/sun/otenf71tsZmagIE/bejne.html
Personally, the only thing I hate is the fact that no-one teaches Computer Science any more. They might call it computer science, but it's actually Browser-Science. i.e. They teach how to get a web-browser to do something, but completely neglect teaching things like how to create a system that factually works, where the browser is a component of said system.
On the subject of shiny things: back in the early 80's when I was working in banking writing ATM networks an MBA decided to program a weekly business accounts summary in APL. He showed the auditor how to run the program which took hours to run and brought the mainframe to its knees. I could not watch this so I wrote the report in a scripting language and gave it to operations to run every week. The auditor was eternally grateful. The MBA took me across the hall into the bank vault and balled me out for being unprofessional.
"No good deed goes unpunished." Right?
@@markhathaway9456 The story of my life.
Great content, thank you for your services to software engineering.
The evil of software is its developers - and especially managers who don’t know their tech
The less my manager knows about tech the more I expect they delegate and trust their team. Managers are suppose to clear roadblocks and enable the team. And yes, sometimes poor developers are those roadblocks.
@@haxi52 but when they give a steer, HR are there to say you must follow it, although it is likely wrong
@@stephendgreen1502 If HR is involved in steering a dev project, that's a completely different problem to have.
@@haxi52 not uncommon though - it happened in two of my last three jobs
Hey Dave. Can you show us the alternative to feature branching and pull requests?? Not just describe it, but demonstrate it.
I love how you talk about architecture, yet in my 10 years of working I have met only 2 people capable software architects. So the problem is IMO rather simple 90% of developers are poor architects because it is not a commonly taught skill. You'd find in beginner tutorials, etc.. I am not a good architect myself and that makes it even harder to educate others about the problem or push for the better change.
It is a tough problem, and I agree, the problem is that it is poorly taught, and we don't value it enough as a skill. Good architects are scarce, but the good ones make a big difference. I'd recommend Gregor Hohpe's stuff kzhead.info/sun/mLGrnaWmapSPnIE/bejne.html if this is a topic that interests you, and this: kzhead.info/sun/eNCGnqx8iniXdq8/bejne.html
In my opinion it’s more of a mindset than a skill that can be taught, and yes, good architects are as rare as hens teeth
Start with design patterns, they will help to learn seeing patterns and object oriented design will help you to learn how to identify boundaries. Eventually your understanding starts to scale up, from one module to a couple of modules, then to a whole service, bunch of services, to a whole software system. Excellent book is Domain-Driven Deign by Eric Evans, after you have some insight into object oriented design, this book will level up your architectural skills.
It’s a poorly taught skill because it goes against everything we teach brand new developers. Look at Tibor’s response. He’s telling you to learn Domain Driven Development. While that can be a useful tool, it’s completely orthogonal to being a software architect. If we want good software architects, we have to get out of the mindset of “here’s your hammer, keep hitting the code until it works”. The job of a software architect is to look at the toolbox, think about what advantages and disadvantages each tool brings, and then design the system around the goals for the software/hardware solution. That requires a lot of knowledge and taking the time to understand *why* each technology exists. For example, you should NOT use an SPA unless there’s a distinct benefit to remaining within a single, unchanging interface. That interface must be complex enough to justify the overhead as well. Yet most so-called architects use “popularity’ and “shiny hammer syndrome” as shortcuts for critically evaluating the technologies. And that’s why so many projects suffer under the use of an SPA framework like Angular or React. That’s just not the way the average developer thinks or is taught to think. If they think at all. There are so few qualified software engineers that the industry is obsessed with trying to use less qualified people to do more work. But I honestly think we’ve exceeded any and all returns on that plan. We need to contract back to capable engineers and focus on better quality software that takes less time to write. Order of magnitude improvements in productivity are possible. I’ve achieved them in teams as an architect, hitting as high as 100x performance. (TWO orders!) But it requires discipline and deep knowledge of what you’re doing.
Wait until AI takes over software development. Trained on the latest code trends. Then you will see some really bad code.
Fully agree with your comment on Frameworks. Frameworks restrict. In some cases, that is no problem. But in most it becomes a problem at some point. If only because it gets outdated and turns out to be closely-coupled to your code, so replacing it with something new is nigh-on impossible. With libraries, it is usually trivial to create an adapter layer to mimic the old behaviour with a new library. With framework this is not the case.
Thanks for the video =)
Leetcode. Tells you nothing about how someone is as an engineer, but it's ubiquitous. It's a lazy interview technique which shows no thought into what you actually want from an engineer.
Complexity is the challenge without a doubt! Creating a data structure that tell the entire story of the project is what I love doing.
TY for reading our (sometimes) stupid tweets. You made great content with them.
When it comes to Code Review vs Pair Programming, I have never met anyone who treated PP as form of code review. And by code review, it is almost always meant an asynchronous pull-request model. Hell, I remember someone saying that even if the code was pair-programmed, it still needs to be turned into a pull request and reviewed by someone who didn't write the code.
We haven't officially met but I will say I am someone who has worked for years using pair programming as an alternative to code reviews, at least 95% of the time. Required code reviews after pair programming is extremely inefficient in my experience.
We haven't met either, but that is how my teams did code review for the past 20 odd years. You don't need PRs if you are pairing, that is crazy!
Every real code review will turn into a pair programming session. You should just save the time and pair from the start.
PP one of the biggest wastes of time that every existed.
@@eyesopen6110 Ironic name. Question for you: If pairing is such a waste of time, how do you accomplish your QA? Do you have a separate QA person test the change _after_ you finish building it? If so, THAT is the real inefficiency. If you’re pairing up, you can QA the changes as you build them thanks to Continuous Integration. Which means that QA is done almost as soon as code is done. If you’re serializing the process, then you not only have to wait on the QA person, but you’re going to have locking problems where the developer will take something up while waiting for QA, and QA will take something on waiting for DEV, and before you know it you have a massive inventory of “in progress” work. Which we know from Little’s Law will increase time to complete each task and lower your throughput.
I've been intrigued by Scala 3 because it seeks, like some other languages, simpler syntax with a lot more tools to do various things. There are also a compiler, a JVM version, a script-runner, and so on. It isn't enough to have a 1970's C with one compiler for all uses. The next question beyond these technical tools in a simple package is how do we tackle the complexity of design issues. I don't think syntax by itself solves it. I was taught that top-down design with several layers to develop the implementation would enable one to think of parts of the problem space at differing levels of abstraction. That is hardly discussed these days, so I suspect most people see it as impossible to solve or solved, one or the other. But people still talk about the complexity and I don't hear hype about all the different ways to solve it.
Dave, you nailed it again!
As far as pull requests/feature branching/code review - What would you do in a situation where the team is fully asyncronous and in different time zones? I can't think of a way to handle that well without PRs since you can't do proper pair programming. What would you suggest?
I'd do pair programming during the timezone overlaps, or maybe mob programming, and work alone during the rest of the time. I add Non-blocking code reviews instead of PRs for everything else. I describe NBCR here: kzhead.info/sun/itGPlZWJqYmujI0/bejne.html
@@ContinuousDelivery so basically find a way to have overlap where the team pair/mob programs and prioritize that? Gotcha. I've never heard about non block code reviews before I'll check that out thanks for the suggestions!
@@unitydev457 Yes, I once spent about 3 years as part of a team split between London and Chicago, our timezones overlapped by at most 3 hours. But we paired for most of that 3 hours, and found it a great way to keep the team together and focussed on common goals and still learning from one another.
@@ContinuousDelivery I've been doing feature branching/ pull requests, and mostly async work for past few jobs and it worked okay when everyone was senior and knew their responsibilities but in latest role I have a few much more junior teammates and I've noticed that it has been leading to situations where we spend 5 minutes talking about a problem, and then they take days over engineering a solution instead of the 10 minutes it would take if we just did it on the spot together. I don't know if the answer is to radically change how we do everything as far as CI/CD right now, but definitely going to try incorporating more pair programming into the workflow
My biggest hates, move fast and break things which translates to I want to be stupid and sloppy, node and git, that over-engineered and ridiculously complex version control that you can't use properly without a command line. I will give an honorable mention to the vile editor only because I'm not forced to use it.
100% agree on the agile part. I used to work in corporate environments and while there saw better and worse implementations of agile development. Now I'm in a tiny company, in a team of 6 for my peoject and the speed and quality of work would never be possible in even the best agile corporate team. Not even talking about enjoyment. I am sure agility is technically possible in a corporation but it would require management to give up too much power. Not gonna happen.
The funny part is if you have proper org structures, management giving up that power not only makes things better but also makes their lives easier. Agreed that very few people know how to do this.
Agile is like communism, it only works in heaven where everything is perfect already therefore not needed and does not work in hell where they already have it.
As an embedded programmers working with firmware, drivers, low-level stuff..... I hate the way the web people (or hr?) created the 'fullstack' concept.. as doing web from server to front-end is the WHOLE and any kind of computing...!
I agree that it is a widely abused idea, did you see this video on that topic? kzhead.info/sun/ndSLhNOmg3V3naM/bejne.html
It's a HR concept rather than CS concept
I missed the tweet, but #1 on my list is Dunning Kruger. The effect that has on software can be very disruptive.
Don´t be alarm but you have an alien inside
Where can I get that t-shirt?
The T-shirts are from QWERTEE who give a special discount to CDonYT followers! 🔗 Check out their collection HERE: bit.ly/3vTkWy3 USE THIS DISCOUNT CODE: ContinuousDelivery
What do I hate about software? The people who don't change it. Software, by nature, can always be changed. As a professional, not working towards making software better, means you're not being the best you can be, either through laziness or maybe your manager isn't supporting you, or it doesn't make sense to the business when they have bigger fish to fry.
Finally, a video to unite all devs :D
or tear them apart
@@coryserratore5951 Nothing unites devs more than tearing each other apart.
Scrum. SAFe. Project Managers. Jira. Java. "I have all the answers" experts. Silly meetings.
Because you're obviously very thoughtful about what you do, you think of yourself as a designer of software, and you mention the lack of any real progress in GUI programming models since the 1990s, I have to ask: Is there any body of knowledge on GUIs? I've been struggling to find some sage advice on the topic, but most is either promoting a fad framework or misapplying model-view-controller with simple, stateless examples. I found some interesting work that Martin Fowler did in the early noughties... Abandoned, of course. Everyone got so excited about the web back then... The gold in them hills. HTML was the only view-model that mattered, and the rest of it went to sleep until AJAX brought about the JavaScript revolution. But these frameworks seem to exist largely to disguise the raw facts about programming for a web client. Making it into something else. If you don't already know what's underneath, they'll inhibit your understanding, rather than enhance it. And as for how to structure a GUI programme, they only muddied the waters. Academics don't teach GUIs because, I suppose, they feel like more of an engineering problem, best solved by industry. And so, knowing how to build them well becomes a niche topic, kept alive by specialists in industry guilds. To learn their secrets, you have to be very lucky, appearing nearby at exactly the time when the old pros could use a helping hand. You must be very young and preferably remind them of themselves. And this generally happens by accident, rather than by design. So I suppose I'd name this _niche knowledge_ as my pet hate. You'll be reading some doc that seems to be written in ancient Sumerian, and you'll realise... It's defining everything in terms of some previous paradigm that it hopes to replace. But you're reading this long after it's succeeded in completely papering over the old paradigm, which is now lost to the mists of time. If you don't already know, at best you'll have no access to the people who do, or to their body of knowledge. At worst, you'll be down-voted and laughed off the net for having had the temerity to ask about something that isn't currently trendy. That's what I hate.
Having to pair with devs who don’t know their trade but insist on teaching it to you. Ugh!
That tends to happen a lot.
Some of the items on your hate list a pretty general but agree mostly. And the selection misses "Code generators".
How would you do trunk development instead of branching when working on a live game that is actively being played and tested while also still in development? Where 100+ people are simultaneously working on new long term feature development, new tech to establish while at the same time players test your alpha version. I really would like to hear someone explain how that scenario is supposed to work without branching and just trunk development.
Not a dev but pretty sure the answer is the master branch lives in dev. No reason I can think of to be pushing untested code to prod on a live app.
1:05 reminded me of one; a smug sense of superiority.
Error reporting in most software. Perhaps "hate" is not the right word, but it is something in which we have a lot of room for improvement.
From those tweets I feel like the set of things that people hate is the set of things that people use.
I don’t hate comments as much as other people seem to. “Self-documenting code” is very subjective.
My take is if it tells you what the code does, it is wrong, superfluous. if it tells you why you chose that way for the code to work, then may be useful. So most comments are a wast of time, because they tend to simply repeat what the code says, or should say.
Code I see nowadays doesn't really look any better or worse than that from 20 years ago. The only difference is it does not have any comments.
@@ContinuousDelivery I like the code to tell the developer the context behind the block of code, why have we made this choice and what Is the workflow. In fact I generally write the comments first then fill in the code. Even having the green blocks as an easy to parse method of reading the workflow helps.
Feature-branching and PRs what we have at our team and it works great. Is not perfect, but it would be much worse without that
That's fine if you are satisfied, but what data there is, and how the orgs that we think of as "great" at SW dev work disagrees with you. FB & PRs are negatively correlated with high performing teams based on measures of stability & throughput.
Presumably more experienced people apparently, if we're questioning whether the audience is male. Naybe we're all really 14 year old girls. That's the demographic that loves senior+ software delivery content the most.
Prove to me that your code has been tested, peer reviewed, had some static analysis ran on it, your test coverage meets demands, link a PBI and that your code meets standards all without a pull request or without using my time to physically show me
I don't have to prove anything to you 🤣, but since you ask, despite the rather rude way that you asked the question... I led a team that built one of the world's highest performance financial exchanges and operates in regulatory regimes in several different parts of the world. This was heavily regulated software, first under the rules of the FCA (originally the FSA) in the UK. We had to prove all of these things to them for any change, and we did so on an automated basis as a side effect of the way that we worked, including pair programming, TDD, TBD, CI and all of the other practices that I recommend on this channel. I later consulted with Siemens Healthcare, who did much the same, but this time for medical devices the could kill people if they went wrong, and the regulators were still ok with it. Not only is this possible, I would argue that it is close to impossible without these ways of working: I argue that case here: www.davefarley.net/?p=285
I hate automatically generated 'documentation' from comments. Tools like pydoc, doxygen, and javadoc don't lead to documentation that is helpful and clutter the code with many useless comments that point out that the function 'get_height' gets the height.
Yes, Jira is a hideous tool that should only be used for support and not for development. I agree with you that how it is used, strictly for management purposes really, makes it infinitely worse but if you were to try to use it to manage projects it really doesn't work very well. A simple example, you can't take a Jira issue and break it down into subtasks where if you get those subtasks done the parent is also done. The tool was just not designed to manage project work, it was designed to manage support and those two are not compatible.
Nice shirt.
I hate software frameworks that are great for slapping together a prototype, but for which customizations take more work than coding directly in the base technology. I hate management that refuses to allot time for refactoring or code documentation.
I run into this too, about time allotted to refactoring, or really anything but "delivering features". It's a cultural problem, if you have a superior who won't even entertain the idea of these things being valuable then I would probably just do it without telling them. But if you are competent, assertive and accurate in your speech, that goes a long way to earn respect from people and thus drive through change.
Scrum, which goes against the spirit of Agile. Bad code reviews, that tell you to change things but give no solid reasons to.
Managers love Jira 'cause they can create hundreds of reports with a few clicks.
I don't know Jira, so this is speculation: was it created specifically to serve that dysfunctional joy people get from creating hundreds of reports with a few clicks?
Vanity metrics = vanity results
With respect to blindly copying what other successful business have been doing: I always think its best to do what makes sense for the software today, not what you think might make sense for it in the future. The only way that that thinking should manifest in the software is via the modularity necessary to change your mind on that point down the line.
I hate how fair and balanced this author is, it's too good to be true. He needs some PrimeGen passion and hype! :)
Languages are just interfaces. What's more important are the purpose and function of a software.
*Reactive code* (instead of reactive systems). On the other hand it guarantees my job for the next 10 years to get rid of it 😂 feels same like the COBOL situation.
Someone once told me "Be in software development long enough and you will start hating your users".
I sometimes think that must also be true for doctors who have ill patients that won't change their ways and be well.
Poor or no documentation with the excuse of being Agile or being true Scrum-certified process. That won't make us anymore agile or quick. On the contrary, makes everything slower l, stick and more difficult to escalate
What I hate more than anything.. besides Javascript, .... and standup meeting.., is OPEN SPACE OFFICES!!!! Developers do not work or think as people in HR or other departments!!!
The analogy I often think of is the fiction writer who has his own little office off somewhere in his backyard, away from his home and family and distractions. He goes there to write write write, then returns to Civilization to eat, sleep, and deal with issues.
pull requests of automated tests is a must. Automated tests written poorly leads to a complete disaster
What has the quality of automated tests got to do with "Pull Requests", code review maybe, pull-requests entirely optional, and mostly a waste of time for teams. 😉
@@ContinuousDelivery PRs maybe a waste of time if you have an all senior team, but not when most of them are juniors. Even they all just merge straight to master, well have a quagmire spaghetti mess in two weeks.
Overuse of containers. Docker this docker that, unnecessary use of containers for small and simpler projects that do not require containers. It also feels really weird to see virtual machines in virtual machines using containers, it just feels redundant at some point.
Meetings that take more than 30 minutes and are organized like a broke artist.
Backend people hate JavaScript (and html/css), in other words frontend a lot.
i don't think there's anything wrong with jira, it's a user and administration problem exclusively
Late to the party! I have extreme dislike for constructors that do anything other than initialise field variables. Why do people still do things like initialise a database, or some other heavy lifting in a constructor that can potentially cause object instantiation to blow up? Actually, I even dislike those... I think I just like to see no args constructors only, please. Everything else can be set and/or accessed via methods with the appropriate access specifiers... change my mind!
I hate old school geezers whose favorite activity is bossing people around and always seem to have something to say about everything
I hate that JS is the only language for web development. Also, I hate JS in general and the almost daily birth of a JS framework that'll become the next boom
Still not sold on the idea ditching PR-style code reviews. Yes, they are a crutch, but I haven't found an alternative that works for my teams. Before PRs, it was everyone for themselves and no feedback or mentoring of any kind at all, which served to produce incredibly horrible messes that we still have to deal with. We certainly don't want to go back there. Of course that's not what Dave is suggesting. What he is consistently suggesting is pair programming in place of PRs. And while I think pair programming is a useful technique that I use and encourage a lot, everyone I have ever worked with agrees that it's impossible to do it *all the time*. It's just way too exhausting.
When pair programming you can have one of you create the pr and the other approve it instantly, and when working alone you create the PR and have someone review it like usual
I pair most of my day, with the occasional exception for the simplest of PRs. I found it extremely exhausting in the beginning, but not anymore. I think it just takes some time to get used to. Being remote helps. I couldn't imagine doing this in an office 5 days a week
Same for me. I work in a feature branching PR oriented team and while things are not perfect it could be worse without that in place
To push unfinished work at the end of the day requires some mechanism to block it from the execution path. Not only does this add complexity, it's not ntegrated anymore.
There's nothing wrong with agile, but it's not a replacement for competent leadership.
I agree, but I would day that competent leadership almost certainly has to be agile
100% agree, there's a reason proyects have had and will always have managers, architects, decision-makers.
I hate JavaScript so much I couldn't bring myself to watch your episode on it. And it's not so much the language itself but rather my experience of it making me feel stupid for so long. For context, I'm a 20+ year .NET dev.
Hey Dave, at 13:30 you mention that you value fast feedback and because of that dislike pull request. Could you explain which type of feedback (customer, developer,...) you are referring to?
Pair programming, clearly. With PP, the feedback is immediate. The moment you write the code, your partner reviews it and gives you feedback on it. And as the code is reviewd as it is being written, it can immediately be merged into main, without need to build a "request" to merge it.
I think we should do our best to optimise ALL FEEDBACK to be fast and high-quality. Pair programming gives the fastest/best code-review feedback, automated tests, give fastest/best feedback on whether or not our code works and does what it is meant to. TDD gives fastest feedback on the quality of our designs, a deployment pipeline gives fastest/best feedback on the releasability of our system,.CI gives fastest/best feedback on whether my changes work with yours, or not, and so on and so on.
I hate meaningless code reviews or single person code reviees when a new feature is added. 'LGTM' has become a new curse acronym
I kind of hate how so many people believe "you can do everything with Python"; I always found it as the most useless language because everything is 100x slower
Sorry, slower than what? Are you a C++ coder? Most everything is slower. It's hard to find something that spans the range. Python tries with very low-level stuff in C, but they're still failing. And C++ doesn't serve the rapid-turnaround dreams.
@@markhathaway9456 My estimate is Python will become less preferred as people work with larger amounts of data. It's not a useful language when every language feature outside of vectorized numpy code, is not usable on large data sets. Not to mention it's still *single threaded* when standard consumer cpu's are havinge 16 cores 32 threads. Try Julia as it solving the remaining compile time issues. It has none of the problems I mentioned.
@@KirbyZhang Is Julia compiled, interpreted, or running on a VM also used by other languages?
@@markhathaway9456 it's compiled with a runtime and a REPL
@@KirbyZhang So compiled or interpreted (on it's own VM?)
We should focus on design and have AI tools to organise and lay out our code. Big things first.
"developers" who just ask chat gpt, but who can't dive in and diagnose a problem
How is, “Real Code,” a more desirable attribute than, “working code?” :D
Typically, those who don't like Javascript aren't using it correctly.
scrum = kill it
People who hate Jira don't know how lucky we are.... where I am, we use Redmine.... oooh, I dream of Jira.
Slow compile times. So much time wasted.
thus one reason for the VM languages, but they aren't a complete replacement for fully compiled to the metal languages
Look mum, I'm now a famous "hater" on the internet. Serves me right for posting things on Twitter 😀
Incremental seems better
Waterfall and Scrum
10 years ago i propagated agile, now i hate it most of all
Mob programming.... has to be one of the most expensive and ridiculous ideas I've heard. What a waste of resource.
I admit I thought that when I first heard about it too, but that simply isn't the case, and that has been shown now in lots of teams. Mob programming is surprisingly effective, and it is not a "waste". I talk about it in this video: "Mob Programming Surprised Me" kzhead.info/sun/nM-inKx_kJ1reas/bejne.html
"other people's code"
I hate Windows so much it's unreal. I spent half a year on Fedora and felt like I was trying to save a sinking ship by constantly repairing it. I was thinking "God, Windows was so much more stable and daily use friendly". But when I returned to Windows I was SHOCKED. It is ugly, irritating, full of bloatware and BS nobody asked for, and worst of all it just assumes you are a degenerate, who does not know how to use a computer and should not be trusted with anything. I ran back to Linux as fast as I can and I really have no idea how people can use Windows on their developing machines.
Cd isnt giod if its bad material.
except you find out that it is "bad material" faster, so have the choice to change.
A poor, clunky JIRA implementation is slow feedback that your organisation may be falling foul of conways law