I think too many software developers have forgot this and only care about the technology and not what they are actually solving. I think one of the biggest reason for this is that we are moved more and more away from the source of the problem we are suppose to solve and if we don't understand what we are suppose to solve, we can't solve it.
This is true. I've been referred to as a "Duct tape programmer" by fellow developers, especially the younger grads who focus intently on refactoring and structure. Being that most of our software was short lived and very specific, Marketing referred to me as "the only developer who knows how to make money with software". After 50 years in software development, I cherish both assessments in retirement, even as I still program every day.
I agree with you. But having worked in around two-dozen organisations, the problem is usually one of under-specification, not over-specification. Not least because the people representing the business are oftentimes poor communicators and, surprisingly, have a poor understanding of the business need.
I've seen a little of this from both sides. What seems to happen is the customer's commissioning manager doesn't in reality understand either the problem nor what the users are actually doing. But so long as the process is followed and the boxes checked everyone's happy, right?
When i started to work in 90s, there was barely a role "programmer". We were all "developers". We did most of the business analysis and the rest was just an implementation detail. Programming is just a more detailed way of writing down business requirements. Nothing more.
I've been working in the consulting world for over a decade. To me, more often it isn't poor communication, it's not knowing what is causing the problem. If you don't know what the problem is, you can't possibly design a good solution. This is why open source follows the saying most fast and break things. 90% of the time, you don't know what the solution needs to be until version 3.
over-specification is fine if the stakeholders are willing to deviate in case of "problems". under-specification allows developers to creatively cut down on the amount of work required, but mostly wastes a lot of time if it's bad enough. it can be a delicate balance
For me, the big distinction is "Are you a programmer or are you a software developer? ". Actually writing code is not hard. Working out what code needs to be written is the hard part.
For me it used to be nothing but meetings but nowadays is just keeping up with the software changes and vulnerabilities and security patches that are just non stop. All I do anymore is chase software patches because the developers are writing s*** software that we're forced to use. I've said it before and I'll say it again and again, human beings are great at manufacturing work, and quite often it is useless work.
This correlates well with your other video on estimates, because the need for estimates is the root cause of this dusfunctional workflow. Stakeholders want to know what will be built in detail within a budget and time frame. This causes the cascade of requirements, ui design upfront, and detailed tasks so that developers have no excuse to not estimate. So, unless stakeholders buy into the idea of discovering solutions without a deadline, I don't see it getting any better for most companies.
But isn’t there value in knowing timelines? Even construction or manufacturing is hard with many problems to be solved (similar to his case for software development) but can we do without knowing how much something would cost or time it would take to build? I am willing to be enlightened if I am misunderstanding his argument.
@@dhruvwork Having worked on long software projects for 2 different companies in which both had stakeholders were from the construction background, I can tell you that there is no such parallel between construction and software. Dave explained that already on various videos, and I wish I had watched those before my experiences, but I will try to summarize: In construction, a project has 4 phases: 0: The client wants a new modern building 1: the architect comes up with the concept, 2: the engineer translate that into a blueprint along with the bill of materials and task list. On phases 0-1-2 there will be some iterations between architect and engineer, and possibly the client, but they will eventually compromise on the project and settle for a final version. 3: construction itself. Given the blueprint is settled, the timelines for the tasks are usual and predictable, so it's straightforward to build a timeline on a project management tool, with beautiful and meaningful Gantt charts. Problems will occur on phase 3, as you mentioned, but they are the exception. Whenever they occur, once the tasks needed to overcome it are defined, the project tool can re estimate the timelines. With software development, if we would follow Dave's advice, we would focus only on phase 0 and 1 the entire time, because once a design is final, the cost of production (phase 3) is negligible (typing the code and building the binaries), and so phase 2 (estimating) is absolutely moot. Adding insult to injury on the comparison, when a construction client wants a building, they usually have a pretty final idea to start with. Number of floors, rooms, arch style, etc. So the iterations on construction phases 0-1-2 tend to be small and concern some minor details. On software, the client is always trying to build something innovative, so there is no "clear picture" right at the start. If we had software phases 0 and 1 on construction it would be something like "Now that the foundation and 1st floor is built, we figured out that six floors are not enough, and we want 12 more". The engineer would laugh and say: "well, if you are willing to spend 10 million for us to demolish everything, clean the plot of land and start over, we could do it" I think Dave makes a brilliant point in showing us that most companies will invest a great deal of energy on phase 2 (the blueprint+timelines) and these will be constantly being missed and being changed. Agile was invented to get rid of phase 2, not to produce a better and more precise phase 2 than waterfall. So, budgets and timelines on software should be treated the other way around: the stakeholders fix the budget and timeline, and the team deliver working software regularly, so that phase 0 and 1 are constantly happening until they get a product that they are happy with, or they run out of money and patience.
To get this right, one must overcome another misconception: A huge part of software development is communication: First, to get a mutual understanding of the problem to solve. Then, to break it down into pieces the team can efficiently work on. Getting the code out is also often very communication-heavy: Either you pair or mob on solving a task, or one dev implements it and other devs review it and have to communicate what they would do differently and why. And, of course, good code clearly tells other devs (or your future self) what it does, so it should be clear and easy to understand. That's all communication in different ways.
The ability to ask the right question has earned me the title of "ATM goddess" as well as "the girl who writes code faster than you can sign your name". How did I develop that ability? Majored in English literature. Working on software is like working on any text: research, draft, refinement, repeat. Not to mention: know your audience - both human and machine.
YES, my personal theory is that a large codebase is like a book, it must be cohesive, properly structured in chapters and sections, the meaning conveyed must be clear. So yes programming is technological english literature
i don't mean to be patronising.... but very well done on recognising and making the point in the last sentence. you remind me of a well known quote repeated by Martin Fowler.
@@giorgos-4515 Yes, it's true that one can read well-written code like a book but I think the connection goes deeper. Programs consist of executable and data parts: narrative and description, operator and operand. A thread of execution is like a story with a beginning, a middle, and an end. I could go on...
Ideally there's an open discussion between management, business and development. In practice egoes are big, everyone protects their own interests and everything grinds to a hold. In the end devs are doing the minimum of what they are told, business wishlists are ignored and management steers clear of any 'expensive' ideas (sensible ideas in actual fact).
This definition of software engineering is so good. This has been my experience as I have been progressing in my career. Thanks most notably to a few good mentors.
Software is often part of a bigger system, one too big for any one person or any one development team to understand. This is particularly problematic when the other parts of system are also under development. The larger system could be a set of business processes or the hardware the software is going to run on. In the case of hardware/software co-development, tradeoffs are necessary between the hardware and software. These decisions usually need to be made early. You cannot solve each problem from first principles in an optimal manner. It becomes necessary to make some assumptions about the solution and impose some requirements on the development teams. This restricts the scope of possible solutions and the latitude of the software developers.
I enjoy these, but often disagree more than just a little. The message here seems to be don't over-specify, the delivery team will work it all out. However POs and business are not generally guessing - usually they have context and a view that differs in many ways to the code-centric views of devs. They own the business, the strategy, the value and benefits. It's helpful to the delivery team if the POs include what detail they have up-front, but that doesn't preclude iteration during the sprint. Gosh, Domain Experts might be missing information, but they almost without exception have more knowledge and better routes into the business than devs.
Have you ever seen this work in practice? My guess is no. I think you are making a lot of assumptions, one of which is that devs “just write code” and are somehow stuck outside of the domain. Second, unless POs have vast experience, there is no way they are going understand what questions to ask to get to a solution like a developer would. Too much specificity just wastes time and it almost always gets overwritten. I’m not sure what your role is, but your viewpoint is just plain wrong.
I do often find myself 'whiteboarding' on personal projects and thinking of ways to test/verify. This can lead to a slow start on my own but I also like to know just what it is im trying to fulfill! Moreover, working with others really does help me move faster.
My current customer doesn't allow developers and stakeholders talking to each other in order to understand the requirements because that would undermine the product owners and architects who provide you with the exact requirements and steps to implement them.
I have never thrived in places where I'm just told what to do in code. Especially through a project management system, like Jira. I want social interaction and creative discussions.
Then you would do better in soft skills side instead of the coding side like in UI/UX, project management/business analyst, or even architecture or other design. Entry level "coders" are supposed to execute the designs developed by the experienced members of the team. Very few fresh grads are going to do well designing solutions in enterprise software.
The biggest problem is that everybody think that a Junior Developer can code and that Junior Dev is assigned coding tasks. Instead the Junior Dev should be doing code reviews and discussing architecture with the Seniors.
I have a major release with a customer, and developing these features for the last few days, and I have a bad flu for the last few days, no rest for the developer
I see that this explanation is a sort of bottom-up, reactive one, while I would recommend a top-down, proactive approach. _We build and maintain information systems._ Of course, you ask, what is an information system? The answer is, it is a dynamic abstract replica of a target system: we "extract information" to examine and control it. That target system can be real (a power plant or a vehicle), imaginative (games), or in-between (like financial systems, if you think that's real, ask the crypto guys...) You ask, what is "building" and you find the different levels of learning, organizing and coding. "Maintaining" means no information system is complete, learning does not stop at the moment of the deployment, in fact some of it just starts then. This kind of investigation leads to pretty useful conclusions.
As a game developer, I would say one caveat to this attitude, and specifically to using gamedev as an example, is that game development teams almost always employ designers who have more experience in player-facing creative decision-making. Therefore, when it comes to creative decisions, the designers usually have authority and vetoing power over the coders. However, that's not to say that the code aspect isn't creative in its own right, it's just that the decisions don't tend to have a huge effect on the user experience, and coders still hold authority over designers when it comes to decisions affecting technology or work flows. In this kind of environment though, sometimes it can be genuinely helpful for designers to deeply consider and formalise their decisions into design documentation before handing over to the coders to implement, rather than trusting coders to feel around in the dark.
Unfortunately, I’ve worked at companies where my ideas have been scoffed at. Continuous delivery (no pun intended) is all companies seem to care about. No one wants to listen to ideas like taking the time to clean the code or solving a customer issue that a developer like me pointed out. One time, I found a compliance issue, and not even the compliance team took it seriously. I brought it up in scrum, and no one wanted to deal with it, so I brought it to compliance, and they practically said how dare I (lowly developer) bring this to their attention.
Hi guys, I'm a young guy studying programming with aspirations of becoming a software engineer. What is some advice you would give the younger generation of up and coming devs on how to break into the market, possible tips, approaches to writing code, how one should go about landing good salaries, ect that you wish you would have known earlier. Thanks.
I guess I'm weird, because the "hard" part described is the part that I find exceedingly easy. Problem space exploration and solving is the easy part of engineering for me. For instance. I was working on an issue management system and spent hours trying to get my build to work. It would fail, and no logs would generate. Once I got the build to work, the function wouldn't do what I wanted it to do. I finally figured it out over the weekend. How long did it take for me to figure out the problem I wanted to solve and how to solve it? About 10 minutes.
So much time is wasted on the deployment, environment parts of software dev. currently battling a permissions issue in AWS, took me 5 mins to do the code change and a day (minus meetings) to fail to deploy a working version. Nothing has changed from the previous version in terms of s3. Yes we have pipelines and gitlab ci templates, we use terraform with template repos for common scenarios but its just phenomenal the amount of time that gets wasted across our industry with weird environment issues its always permissions, certs, networking, proxies, VPC's, firewalls causing the issues. We even have an SRE function that are really good, but they are overworked and its not always super clear where the ownership of a problem like this lies, I'd like to get it sorted myself tbh but my younger dev self yearns for simpler times tbh
@@srinivaschillara4023 the issue is technically a bug. But it's because I didn't understand how vercel/postgres handles SQL statements and spent forever trying to figure out why there was an issue. No linter issues, no bugs ChatGPT could find, formatter would format correctly, everything was supposed to behave exactly as I thought it should. But it wasn't. And logs were not generating anything to show what is failing either. If I had infinite knowledge of the programming language and the syntax, the problem would have been solved in 10 minutes. This is generally how all of my development problems are. Because the syntax and knowledge of the tool was out of my reach, I spent hours trying to figure out how to implement the solution I had. I had to rewrite the entire thing a few times to ensure it wasn't a hoisting problem, or a closure issue, or server action problem, or, or, or. And so for me, remembering syntax and language rules and behavior is... definitely the hard part. The problem exploration and solution crafting is not only the fun part, it's the easy part.
@@srinivaschillara4023 the main problem ultimately came down to my SQL database was out of sync with the sequential key. When I seeded the database, I thought it would sync as items went in. Turns out, not the case.
The challenge with software development is that you a creating something that people believe is not constrained by the real world. Say like building a kitchen or making a dress. However there are constraints and the people requesting the outcome inevitably request something vague outside the bounds of the possible and blame everyone in the development for not realising their dream. "Agile" makes this worse as the smart ones know that you can spend 18 months doing the easy stuff and then move on before the impossibility of it hits. Please keep up the good work framing this so it is a better experience for everyone.
In general I think this is correct but you miss some a very important point. It's not usually appropriate to approach every problem as if it were new, the business you are working for tends to have solutions in place. It's a common problem that developers do not want to use existing patterns and re-use already fit for purpose solutions simply due to taste or ego. This can have a huge impact on estimates and delivery. There's a meta-cycle that needs management across a development or project team. It is of course appropriate to move on sometimes but in a controlled way. Not every problem requires a creative solution. Sometimes you just want more of the same!
Dave - I wonder how this works in banking software. It seems in some situations what actually happens needs to be defined very specifically. With the elephant example it’s hard to tell the scale the team should be responsible for - are they given the outline of an elephant when building the earth, and all the animal outlines have been defined or are they just building an elephant simulator. Also if the team has many skills can everyone code? Or is it truly cross functional with product and design people on the team who maybe don’t code at all? I am constantly considering these questions- references would be helpful.
Agile got dinged when product managers who are the so called go between are the single interface between customers and developers. This can lead to a single authority, especially when product manager, invariably, knows how to assert themselves. Developers rarely possess the patience or skill to compete with someone far better at negotiation. I would argue the developer needs to be as much in the face of the customer as the product manager. Too many devs put on the blinders and defer to the pm, because they are uncomfortable in front of the users and customers.
If you want to know if a developer is ready to be a lead, ask them to give you a demo of the software they are currently writing. Most developers will talk about features and the tech stack (we trained them to think this way through micromanagement via project backlogs full of tasks). Someone ready to be a lead will talk about how the customer will use the software and the value it provides. This problem is pervasive throughout IT - it is common to see people focused on technology while ignoring the business context.
You people blame developers too much. We need for non-tech people to take responsibility too and be held accountable. Business people are not as good communicators as they think they are, they don't understand the business as they pretend or they do but are being selfish not wanting to share knowledge with technical team. Scrum Masters and Product Owners. We need those on Dailys providing their status. What they did yesterday? What are they going to do today? How long for them to unblock their blockers. Easy to finger-point to Devs every single time something is not going as you think it should but never really communicated, hoped for Devs to 'find out' instead.
@@errrzarrr actually the gent above - assuming a gent - isnt blaming developers; he says 'we trained them to ... micromanagement.. etc' and this is a very crucial point; my surmise is that this is more true in larger companies than smaller ones.
It's not about leadership. A fault in the industry in general is that we value progress based on ranks like leadership and manager. What about this person who is an awesome dev, but is really not good nor interested in management. Should the manager get more salary when clearly the dev brings more value to the product? I find this sense of "readiness" faulty. But I do agree that when you want to step out of clear dev work, you need to see both sides. Business often doesn't, e.g. like maintenance.
@@chat-1978How can you prove you are bringing more value than someone else? The customer decides on the value provided - if you are saying that caring about what the customer wants means you are no longer a programmer, then no programmer can ever prove they provide value. Just take a few minutes, and learn about your customers and what they want - it isn't that hard, and can completely change your career. It doesn't mean you have to stop being a programmer, or only attend meetings, or anything like that. I have never been a manager - I always turn down those jobs when offered. I was just lucky enough to learn the lessons around proving value to the business pretty early in my career, and it helped me get those non-managerial promotions. To bring it back to the video, if you only turn requirements into code, you are going to be the first person replaced by AI, no matter how good you are at doing that. If you solve problems that the business cares about, you will be too valuable to replace.
Dave would hate the automotive industry. They do the opposite of almost everything he says. Many want software to just be an assembly line where you have "system engineers" who take customer specifications, all the input signals, requirements, and output signals, to generate state machine diagrams, truth tables, etc. - only for the "software developer" to "code it up" like a code monkey...usually somewhere else on Earth. Estimates must target exact Start Of Production dates, which DO NOT move, done by subcontractors (Tier-1's). Requirements involve functional safety & respective processes. Defects in customer specs are reported but often don't get updated into their master docs, repeating problems on subsequent programs. It's a mess....all because the structure of the industry has 100 years of evolution around making a physical part (e.g. a door) as cheaply as possible. Now made worse because the car maker wants to do more of the software but the Tier-1's don't want them to - and they make the final parts. Software isn't an assembly line...but that is how it's generally treated.
You build solutions that fit the (business) need of the organization you wok for. Most of the time that should equal building for the end users, but that depends on the organization and the people that comes up with the need. It is also need to meet a need with expert knowledge of the solution we are building so we can match expectations with reality as early as possible and with that guide towards the best solution together. If the organization is not collaborating, then nothing will work. When a need is being discussed at the business layer, then they need developers to explain how and what to build. When the need is being realized in code, then the developers need the busines side to explain why we build things and to adjust the what and how as we get into the details and might need to adjust things.
Theory vs reality. I'm sometimes puzzled with your background and experience. Either you try to promote the dream, or your experience is very specific and niche. Some videos feel like you have a dream world as a reference. If devs could pursue all of what you describe, then they wouldn't be coding. If you are building a small system, then yeah what you say makes sense. If the system is part of a much bigger system then if everytone did what they discovered it would never work. And those are the easy picks I have on your argumentation. Most developers I've met, there are not competent enough or just don't care to do what you describe and this makes the title of the argument valid. Dev jobs are what doctors jobs used to be in the past. A dollar making job, which many will pursuit for the money and funny thing is that there is so much demand, there is so little risk (people don't die) that the workforce is not capable performing what you say. Have you seen the hiring process? Stepping out of your code requires to a certain point other skills as well. You can be the best coder but that doesn't mean you can enter architect or product owner territory, in a similar way that you can't do testing that well. The helicopter view is not easy, as easy as it may sometimes look. And then there is the business. They often do know, they can't make up their minds, they don't listen and they expect some sort of magic yesterday. Often this leads to going over the same things back and forth and despite the warnings, still actually doing this. I work as a dev, architect and manager for almost 25years in two countries and have collaborated with devs from USA, India and many European nations. There is no way you haven't experienced this reality. I share your vision, the dream if you want, but trying to define a job role based on a dream is kind of misleading to the people who are looking for carreer information. I remember as well doing agile and all the nice things it said about devs being in control. I was also a scrum master and product owner. Hahahahaha. Yeah right. But business, managers and leadership in general have completely different ideas. And I can understand them. It's not that a customer will say, oh your devs are doing what I watched on the video, here you can take 6 months longer. If you were lucky to work and collaborate in all dream locations, then good for you but the reality is not even near to this video.
If I go back to college years, I would learn how to make my employer make more money or save money. Anyway make that possible regardless of my "title" or "career." At the end of the day my employer won't give a s#I^ who I am as long as I have made it possible to make or save money to pay me.
Hi Dave! In your "Acceptance Testing | Webinar" you showed us a great strategy for independent test - such that when you createBook("Continuous delivery"), then in reallity it stores the book in the database as "Continuous delivery1234", to keep them separate. that's a very nice idea. But I have a question, let's image I have a page with a list of books, and when I run tests in parallel, then that list of books shows many books named "Continuous delivery1234". How can I write tests for a page that lists books, if other tests add many books?
I haven't seen the video, but why do you have multiple tests creating books? If you're not testing that method and just need data to work with, you can create some books ahead of time (either with permanent seed data or at the start of the test group for those tests) or have some particular naming scheme particular to the test and making sure to clean up afterwards. There are various strategies bssed on your needs.
You just explained in these 14 minutes why AI is NOT going to replace software developers (and, for that matter, good screenwriters) anytime soon. It's not that AI can't problem solve -- it's that AI can't problem solve creatively.
The videos in this channel are really inspiring for me to let the people in our company and our clients know what to focus on. But reading the comments on this channel and also parts of the videos here make me believe that the world of software development is still so very stuck in the past and people still do not understand what agile means. Agile means agile. There. We started working agile about 10 years ago and really struggled with how to implement all the rules of agile and scrum into our processes. But you know what? There are no rules in agile. Be agile. Try things and if they don't work for your company or your team, try something else. Too many standups? Do less, or make them shorter. Sometimes a project just doesn't go well, so maybe do an extra standup and try to help each other. This video in particular made me realize how well we do, apparently. Sometimes we let the product owner define the backlog. But if the tasks are too technical, we sometimes let a developer define the backlog. During the backlog session however, we let the PO define the problem that should be solved, but often we tell the PO that that shouldn't be the problem to be solved at all. Hell, we often even redefine the stories during the backlog session, because whole new information arises. Also, because of all the talking - which apparently a lot off programmers hate - we sometimes come to the conclusion that with a quick change in code, the PO (or someone else in the client's company) can do the rest of the work to solve the problem. That way the client saves money, or saves time for us to solve another task instead. Everybody happy.
In my opinion, the videos often have an utopia as a reference. The reality is much different. In my opinion, the reason for the reality being so differemt and having such a mess is the fact that most software doesn't kill people, which is why it has attracted such a mix of skill and background. Would you like to drive over a bridge that is built by someone who hasn't studied engineering? Someone who doesn't understand the laws of physics? But you certainly use software that is built by people who have litle knowledge about the domain. People who make decisions with little knowledge. You see UXs that are a joke and wonder how is that possible? Did you play test this? And it's getting worse, everywhere where software becomes more dominant, like e.g. cars. I guess the soft part brings the best and the worse in an explosive mix. But thinking there is only the best, is dreaming and to a certain point misleading.
I agree with what you are saying, but I was annoyed by the extra long waffle at the beginning. If you want to produce good videos, get down to business fast and cut the crap. You can't tell someone to like something, especially before they have watched it. Second point is, you really need to talk to the idiots who face the programmers when looking for jobs. I see a list of some ten or more languages, operating systems, libraries and other acronyms laid out like buzzwords with no bloody idea what they are trying to produce. Software can produce just about anything, and whether you think you will be any good for them is a matter of what kind of programming they want. I prefer to write in C these days as writing code in about ten languages simultaneously is only something a madman would do. It would confuse the hell out of you, so with corporate jobs, surely you don't change the language every 5 minutes. Like what Adam Smith was saying about division of labour. Your issue seem to come from a faulty recruitment process. You get what you ask for. I've got to say the number one reason I have not bothered replying to a job ad is this thing that the recruiter has not got a clue what they are talking about, like Chinese whispers I suppose. Anyhow I know the software is done badly. We get to see it on all of these websites that are the product of British firms. I had some fun with the Farnell website. It asked specifically for a password with non alphanumeric characters. I use a *, but the * in the password crashed the web server for several hours. I tried to log in again and it crashed it the following day. Each time they had it back up and running again I could knock the entire system out lol. In the end I placed the order with another firm.
The hiring process is seriously at fault. Most recruiters have no clue what the people they are looking for do. They use all this fancy words about passion etc but literally it's a sales job and internally the terms used are all from sales and the incentives are also sales driven. I've met recruiters who were travel agents, retail shop empoyees etc. I've been to interviews that I had to explain to the recruiter what they were looking for. I've been to interviews where language compatibility was a problem to begin with.
But isn’t there value in knowing timelines? Even construction or manufacturing is hard with many problems to be solved (similar to his case for software development) but can we do without knowing how much something would cost or time it would take to build? I am willing to be enlightened if I am misunderstanding his argument.
I hold the view that other than a CEO and a programmer, no other role int his industry is well defined, understood or has a strong consensus view formed around it, now you say that even a developer's role - is that different to a job - is muddy..... if i may, the comments on your videos are pretty intelligent, a rarity on yt.
I agree that developer can be more than some mindless ribosome and able to creatively self-deliver out of the box protein much needed by the organism. however for a reason, nature herself decides to create majority of ribosome to be mindless and to become part of bigger mechanism that works well. by the way, wouldn't it wonderful if we can interface with AI to create full software program free from bugs?
As much as I agree to this, larger organizations just can't sustain this. It's great for small projects but when you have a revolving door of people, limited resources and time, you will need scope and accountability which only an organized team structure can provide.
Part of the reason is the "programmer culture". Since they start dress and act like kids, they are of course treated as kids. How can a man put dozens of coca cola cans in his shelf and be proud of it? Why does he wear a hoodie in the office and a worn T-shirt? Taking his useless "cool" tech gadges to work? And beside that there are no team culture to speak of. The developer doesnt want help when offered (to not loose face and appear incompetent), but also dont want to help his team mates (since he is "busy").
@@mdesnica”dressing like kids” is just your projection. Programmers don’t care. Programmers not cooperating is something completely different. Yes, programmers should cooperate.
I have noticed that a lot of developers are just into development because of their coding skills rather than the interest in understanding and building a product. This is noticeable in how there is a demand for backend developers that are divorced from the concerns a the user's perspective. What is a problem then? Just a part of your code doing something for someone undefined whose shoes you will never wear. I have also started thinking whether or not the complexity of software development, and the lack of personal motivation to learning and exploring, is affecting the industry to a high degree. Especially now when companies are trying to change culture to be more innovative and also collaborative. What about women?
The problem is a complex task to be solved. In itself, it is neither pleasant nor unpleasant; our attached feelings are learned. Things do not change by renaming them and searching for another word that currently has a pleasant effect; we just lose a new word over time.
i think coding is the hard part, one of many hard parts that need to come together. the problem with thinking that coding is the easy part is when you're the developer and you see the design for the first time ever a week before launch.
Is this geared only towards junior positions? Mr. Farley is being captain obvious, software development is what he says it is, most of us know that. There's no need to explain the obvious, those who don't get it, shouldn't really be in this. I've been writing code for over 30 years, I want some interesting and controversial content.
My point is that while I think that most experienced developers would agree with what I say, almost no sw dev companies work like that. So it may be obvious, yet we don't act on the obvious.
I think too many software developers have forgot this and only care about the technology and not what they are actually solving. I think one of the biggest reason for this is that we are moved more and more away from the source of the problem we are suppose to solve and if we don't understand what we are suppose to solve, we can't solve it.
This is true. I've been referred to as a "Duct tape programmer" by fellow developers, especially the younger grads who focus intently on refactoring and structure. Being that most of our software was short lived and very specific, Marketing referred to me as "the only developer who knows how to make money with software". After 50 years in software development, I cherish both assessments in retirement, even as I still program every day.
I agree with you. But having worked in around two-dozen organisations, the problem is usually one of under-specification, not over-specification. Not least because the people representing the business are oftentimes poor communicators and, surprisingly, have a poor understanding of the business need.
This 😢
I've seen a little of this from both sides. What seems to happen is the customer's commissioning manager doesn't in reality understand either the problem nor what the users are actually doing. But so long as the process is followed and the boxes checked everyone's happy, right?
When i started to work in 90s, there was barely a role "programmer". We were all "developers". We did most of the business analysis and the rest was just an implementation detail. Programming is just a more detailed way of writing down business requirements. Nothing more.
I've been working in the consulting world for over a decade. To me, more often it isn't poor communication, it's not knowing what is causing the problem. If you don't know what the problem is, you can't possibly design a good solution. This is why open source follows the saying most fast and break things. 90% of the time, you don't know what the solution needs to be until version 3.
over-specification is fine if the stakeholders are willing to deviate in case of "problems". under-specification allows developers to creatively cut down on the amount of work required, but mostly wastes a lot of time if it's bad enough. it can be a delicate balance
"Farley lost it again" episodes are the best episodes - right on the edge.
For me, the big distinction is "Are you a programmer or are you a software developer? ". Actually writing code is not hard. Working out what code needs to be written is the hard part.
Writing good code is hard. Writing bad code is easy (and ridiculously costly for the business).
For me it used to be nothing but meetings but nowadays is just keeping up with the software changes and vulnerabilities and security patches that are just non stop. All I do anymore is chase software patches because the developers are writing s*** software that we're forced to use. I've said it before and I'll say it again and again, human beings are great at manufacturing work, and quite often it is useless work.
sounds very relatable. so many useless riddles that need to be solved
Nah. 9/10 times we have to deal with LACK of especification rather than over-specification
It's problem-solving and building stuff. People get that wrong all the time.
This correlates well with your other video on estimates, because the need for estimates is the root cause of this dusfunctional workflow. Stakeholders want to know what will be built in detail within a budget and time frame. This causes the cascade of requirements, ui design upfront, and detailed tasks so that developers have no excuse to not estimate.
So, unless stakeholders buy into the idea of discovering solutions without a deadline, I don't see it getting any better for most companies.
But isn’t there value in knowing timelines? Even construction or manufacturing is hard with many problems to be solved (similar to his case for software development) but can we do without knowing how much something would cost or time it would take to build?
I am willing to be enlightened if I am misunderstanding his argument.
@@dhruvwork Having worked on long software projects for 2 different companies in which both had stakeholders were from the construction background, I can tell you that there is no such parallel between construction and software. Dave explained that already on various videos, and I wish I had watched those before my experiences, but I will try to summarize:
In construction, a project has 4 phases: 0: The client wants a new modern building 1: the architect comes up with the concept, 2: the engineer translate that into a blueprint along with the bill of materials and task list. On phases 0-1-2 there will be some iterations between architect and engineer, and possibly the client, but they will eventually compromise on the project and settle for a final version. 3: construction itself. Given the blueprint is settled, the timelines for the tasks are usual and predictable, so it's straightforward to build a timeline on a project management tool, with beautiful and meaningful Gantt charts.
Problems will occur on phase 3, as you mentioned, but they are the exception. Whenever they occur, once the tasks needed to overcome it are defined, the project tool can re estimate the timelines.
With software development, if we would follow Dave's advice, we would focus only on phase 0 and 1 the entire time, because once a design is final, the cost of production (phase 3) is negligible (typing the code and building the binaries), and so phase 2 (estimating) is absolutely moot.
Adding insult to injury on the comparison, when a construction client wants a building, they usually have a pretty final idea to start with. Number of floors, rooms, arch style, etc. So the iterations on construction phases 0-1-2 tend to be small and concern some minor details.
On software, the client is always trying to build something innovative, so there is no "clear picture" right at the start.
If we had software phases 0 and 1 on construction it would be something like "Now that the foundation and 1st floor is built, we figured out that six floors are not enough, and we want 12 more". The engineer would laugh and say: "well, if you are willing to spend 10 million for us to demolish everything, clean the plot of land and start over, we could do it"
I think Dave makes a brilliant point in showing us that most companies will invest a great deal of energy on phase 2 (the blueprint+timelines) and these will be constantly being missed and being changed.
Agile was invented to get rid of phase 2, not to produce a better and more precise phase 2 than waterfall.
So, budgets and timelines on software should be treated the other way around: the stakeholders fix the budget and timeline, and the team deliver working software regularly, so that phase 0 and 1 are constantly happening until they get a product that they are happy with, or they run out of money and patience.
To get this right, one must overcome another misconception: A huge part of software development is communication: First, to get a mutual understanding of the problem to solve. Then, to break it down into pieces the team can efficiently work on. Getting the code out is also often very communication-heavy: Either you pair or mob on solving a task, or one dev implements it and other devs review it and have to communicate what they would do differently and why. And, of course, good code clearly tells other devs (or your future self) what it does, so it should be clear and easy to understand. That's all communication in different ways.
The ability to ask the right question has earned me the title of "ATM goddess" as well as "the girl who writes code faster than you can sign your name". How did I develop that ability? Majored in English literature. Working on software is like working on any text: research, draft, refinement, repeat. Not to mention: know your audience - both human and machine.
YES, my personal theory is that a large codebase is like a book, it must be cohesive, properly structured in chapters and sections, the meaning conveyed must be clear. So yes programming is technological english literature
i don't mean to be patronising.... but very well done on recognising and making the point in the last sentence. you remind me of a well known quote repeated by Martin Fowler.
@@giorgos-4515 yes, it is called literate programming an idea etiher germinated by D Knuth or promoted.
@@giorgos-4515 Yes, it's true that one can read well-written code like a book but I think the connection goes deeper. Programs consist of executable and data parts: narrative and description, operator and operand. A thread of execution is like a story with a beginning, a middle, and an end. I could go on...
Ideally there's an open discussion between management, business and development. In practice egoes are big, everyone protects their own interests and everything grinds to a hold. In the end devs are doing the minimum of what they are told, business wishlists are ignored and management steers clear of any 'expensive' ideas (sensible ideas in actual fact).
I prefer to think of my job as a reality modeler. We need to take the real world process and model it in software.
This definition of software engineering is so good. This has been my experience as I have been progressing in my career. Thanks most notably to a few good mentors.
Boss: Write me a software that makes me rich
Dev: How rich?
Boss: Very very rich
Software is often part of a bigger system, one too big for any one person or any one development team to understand. This is particularly problematic when the other parts of system are also under development. The larger system could be a set of business processes or the hardware the software is going to run on. In the case of hardware/software co-development, tradeoffs are necessary between the hardware and software. These decisions usually need to be made early. You cannot solve each problem from first principles in an optimal manner. It becomes necessary to make some assumptions about the solution and impose some requirements on the development teams. This restricts the scope of possible solutions and the latitude of the software developers.
I enjoy these, but often disagree more than just a little.
The message here seems to be don't over-specify, the delivery team will work it all out.
However POs and business are not generally guessing - usually they have context and a view that differs in many ways to the code-centric views of devs. They own the business, the strategy, the value and benefits. It's helpful to the delivery team if the POs include what detail they have up-front, but that doesn't preclude iteration during the sprint.
Gosh, Domain Experts might be missing information, but they almost without exception have more knowledge and better routes into the business than devs.
Have you ever seen this work in practice? My guess is no. I think you are making a lot of assumptions, one of which is that devs “just write code” and are somehow stuck outside of the domain. Second, unless POs have vast experience, there is no way they are going understand what questions to ask to get to a solution like a developer would. Too much specificity just wastes time and it almost always gets overwritten. I’m not sure what your role is, but your viewpoint is just plain wrong.
Have I seen what work in practice?
A quote from Thomas Betts' talk "Leveling up Your Architecture Game" came to my mind: Every software problem is funamentally a communication problem.
I do often find myself 'whiteboarding' on personal projects and thinking of ways to test/verify.
This can lead to a slow start on my own but I also like to know just what it is im trying to fulfill! Moreover, working with others really does help me move faster.
My current customer doesn't allow developers and stakeholders talking to each other in order to understand the requirements because that would undermine the product owners and architects who provide you with the exact requirements and steps to implement them.
I have never thrived in places where I'm just told what to do in code. Especially through a project management system, like Jira. I want social interaction and creative discussions.
Then you would do better in soft skills side instead of the coding side like in UI/UX, project management/business analyst, or even architecture or other design. Entry level "coders" are supposed to execute the designs developed by the experienced members of the team. Very few fresh grads are going to do well designing solutions in enterprise software.
@@morganseppy5180 What are you implying? I have 10 years of experience in software development.
Programming = discovery
Wonderfully explained
The biggest problem is that everybody think that a Junior Developer can code and that Junior Dev is assigned coding tasks. Instead the Junior Dev should be doing code reviews and discussing architecture with the Seniors.
I have a major release with a customer, and developing these features for the last few days, and I have a bad flu for the last few days, no rest for the developer
Great talk as always!!!
I see that this explanation is a sort of bottom-up, reactive one, while I would recommend a top-down, proactive approach. _We build and maintain information systems._ Of course, you ask, what is an information system? The answer is, it is a dynamic abstract replica of a target system: we "extract information" to examine and control it. That target system can be real (a power plant or a vehicle), imaginative (games), or in-between (like financial systems, if you think that's real, ask the crypto guys...) You ask, what is "building" and you find the different levels of learning, organizing and coding. "Maintaining" means no information system is complete, learning does not stop at the moment of the deployment, in fact some of it just starts then. This kind of investigation leads to pretty useful conclusions.
As a game developer, I would say one caveat to this attitude, and specifically to using gamedev as an example, is that game development teams almost always employ designers who have more experience in player-facing creative decision-making. Therefore, when it comes to creative decisions, the designers usually have authority and vetoing power over the coders. However, that's not to say that the code aspect isn't creative in its own right, it's just that the decisions don't tend to have a huge effect on the user experience, and coders still hold authority over designers when it comes to decisions affecting technology or work flows. In this kind of environment though, sometimes it can be genuinely helpful for designers to deeply consider and formalise their decisions into design documentation before handing over to the coders to implement, rather than trusting coders to feel around in the dark.
Well done video.
Unfortunately, I’ve worked at companies where my ideas have been scoffed at. Continuous delivery (no pun intended) is all companies seem to care about. No one wants to listen to ideas like taking the time to clean the code or solving a customer issue that a developer like me pointed out. One time, I found a compliance issue, and not even the compliance team took it seriously. I brought it up in scrum, and no one wanted to deal with it, so I brought it to compliance, and they practically said how dare I (lowly developer) bring this to their attention.
words of wisdom indeed 👍
Thank you for that video.
Hi guys, I'm a young guy studying programming with aspirations of becoming a software engineer. What is some advice you would give the younger generation of up and coming devs on how to break into the market, possible tips, approaches to writing code, how one should go about landing good salaries, ect that you wish you would have known earlier. Thanks.
I guess I'm weird, because the "hard" part described is the part that I find exceedingly easy. Problem space exploration and solving is the easy part of engineering for me.
For instance. I was working on an issue management system and spent hours trying to get my build to work. It would fail, and no logs would generate. Once I got the build to work, the function wouldn't do what I wanted it to do. I finally figured it out over the weekend.
How long did it take for me to figure out the problem I wanted to solve and how to solve it? About 10 minutes.
So much time is wasted on the deployment, environment parts of software dev. currently battling a permissions issue in AWS, took me 5 mins to do the code change and a day (minus meetings) to fail to deploy a working version. Nothing has changed from the previous version in terms of s3. Yes we have pipelines and gitlab ci templates, we use terraform with template repos for common scenarios but its just phenomenal the amount of time that gets wasted across our industry with weird environment issues its always permissions, certs, networking, proxies, VPC's, firewalls causing the issues. We even have an SRE function that are really good, but they are overworked and its not always super clear where the ownership of a problem like this lies, I'd like to get it sorted myself tbh but my younger dev self yearns for simpler times tbh
could it be that your working in a brownfield situation - bug fix - means that analysing the problem is easy, relatively speaking...
@@srinivaschillara4023 the issue is technically a bug. But it's because I didn't understand how vercel/postgres handles SQL statements and spent forever trying to figure out why there was an issue. No linter issues, no bugs ChatGPT could find, formatter would format correctly, everything was supposed to behave exactly as I thought it should. But it wasn't. And logs were not generating anything to show what is failing either.
If I had infinite knowledge of the programming language and the syntax, the problem would have been solved in 10 minutes. This is generally how all of my development problems are.
Because the syntax and knowledge of the tool was out of my reach, I spent hours trying to figure out how to implement the solution I had. I had to rewrite the entire thing a few times to ensure it wasn't a hoisting problem, or a closure issue, or server action problem, or, or, or.
And so for me, remembering syntax and language rules and behavior is... definitely the hard part. The problem exploration and solution crafting is not only the fun part, it's the easy part.
@@srinivaschillara4023 the main problem ultimately came down to my SQL database was out of sync with the sequential key. When I seeded the database, I thought it would sync as items went in. Turns out, not the case.
@@connorskudlarek8598 looks like it was a technical hitch at the backend, not exactly a functional/design problem. tricky stuff to fathom and fix.
I am wearing shirts with software memes, the inspiration was the shirts of Dave
a good celebration for video #256 would be interesting, congrats!
The challenge with software development is that you a creating something that people believe is not constrained by the real world. Say like building a kitchen or making a dress. However there are constraints and the people requesting the outcome inevitably request something vague outside the bounds of the possible and blame everyone in the development for not realising their dream. "Agile" makes this worse as the smart ones know that you can spend 18 months doing the easy stuff and then move on before the impossibility of it hits.
Please keep up the good work framing this so it is a better experience for everyone.
Thanks for the video =)
In general I think this is correct but you miss some a very important point. It's not usually appropriate to approach every problem as if it were new, the business you are working for tends to have solutions in place. It's a common problem that developers do not want to use existing patterns and re-use already fit for purpose solutions simply due to taste or ego. This can have a huge impact on estimates and delivery. There's a meta-cycle that needs management across a development or project team. It is of course appropriate to move on sometimes but in a controlled way. Not every problem requires a creative solution. Sometimes you just want more of the same!
Dave - I wonder how this works in banking software. It seems in some situations what actually happens needs to be defined very specifically. With the elephant example it’s hard to tell the scale the team should be responsible for - are they given the outline of an elephant when building the earth, and all the animal outlines have been defined or are they just building an elephant simulator. Also if the team has many skills can everyone code? Or is it truly cross functional with product and design people on the team who maybe don’t code at all? I am constantly considering these questions- references would be helpful.
Agile got dinged when product managers who are the so called go between are the single interface between customers and developers. This can lead to a single authority, especially when product manager, invariably, knows how to assert themselves. Developers rarely possess the patience or skill to compete with someone far better at negotiation. I would argue the developer needs to be as much in the face of the customer as the product manager. Too many devs put on the blinders and defer to the pm, because they are uncomfortable in front of the users and customers.
"All Life is Problem Solving" - Karl Popper 👍
Thanks!
very well said.
If you want to know if a developer is ready to be a lead, ask them to give you a demo of the software they are currently writing. Most developers will talk about features and the tech stack (we trained them to think this way through micromanagement via project backlogs full of tasks). Someone ready to be a lead will talk about how the customer will use the software and the value it provides. This problem is pervasive throughout IT - it is common to see people focused on technology while ignoring the business context.
You people blame developers too much. We need for non-tech people to take responsibility too and be held accountable. Business people are not as good communicators as they think they are, they don't understand the business as they pretend or they do but are being selfish not wanting to share knowledge with technical team.
Scrum Masters and Product Owners. We need those on Dailys providing their status. What they did yesterday? What are they going to do today? How long for them to unblock their blockers.
Easy to finger-point to Devs every single time something is not going as you think it should but never really communicated, hoped for Devs to 'find out' instead.
@@errrzarrr actually the gent above - assuming a gent - isnt blaming developers; he says 'we trained them to ... micromanagement.. etc' and this is a very crucial point; my surmise is that this is more true in larger companies than smaller ones.
It's not about leadership. A fault in the industry in general is that we value progress based on ranks like leadership and manager. What about this person who is an awesome dev, but is really not good nor interested in management. Should the manager get more salary when clearly the dev brings more value to the product? I find this sense of "readiness" faulty. But I do agree that when you want to step out of clear dev work, you need to see both sides. Business often doesn't, e.g. like maintenance.
@@chat-1978How can you prove you are bringing more value than someone else? The customer decides on the value provided - if you are saying that caring about what the customer wants means you are no longer a programmer, then no programmer can ever prove they provide value. Just take a few minutes, and learn about your customers and what they want - it isn't that hard, and can completely change your career.
It doesn't mean you have to stop being a programmer, or only attend meetings, or anything like that. I have never been a manager - I always turn down those jobs when offered. I was just lucky enough to learn the lessons around proving value to the business pretty early in my career, and it helped me get those non-managerial promotions.
To bring it back to the video, if you only turn requirements into code, you are going to be the first person replaced by AI, no matter how good you are at doing that. If you solve problems that the business cares about, you will be too valuable to replace.
All of this is easy if you have a business stakeholder with a vision and the ability to communicate it.
Dave would hate the automotive industry. They do the opposite of almost everything he says. Many want software to just be an assembly line where you have "system engineers" who take customer specifications, all the input signals, requirements, and output signals, to generate state machine diagrams, truth tables, etc. - only for the "software developer" to "code it up" like a code monkey...usually somewhere else on Earth. Estimates must target exact Start Of Production dates, which DO NOT move, done by subcontractors (Tier-1's). Requirements involve functional safety & respective processes. Defects in customer specs are reported but often don't get updated into their master docs, repeating problems on subsequent programs. It's a mess....all because the structure of the industry has 100 years of evolution around making a physical part (e.g. a door) as cheaply as possible. Now made worse because the car maker wants to do more of the software but the Tier-1's don't want them to - and they make the final parts. Software isn't an assembly line...but that is how it's generally treated.
Dave should've worn a Donkey Kong shirt for this one!
You build solutions that fit the (business) need of the organization you wok for. Most of the time that should equal building for the end users, but that depends on the organization and the people that comes up with the need. It is also need to meet a need with expert knowledge of the solution we are building so we can match expectations with reality as early as possible and with that guide towards the best solution together.
If the organization is not collaborating, then nothing will work. When a need is being discussed at the business layer, then they need developers to explain how and what to build. When the need is being realized in code, then the developers need the busines side to explain why we build things and to adjust the what and how as we get into the details and might need to adjust things.
Theory vs reality.
I'm sometimes puzzled with your background and experience. Either you try to promote the dream, or your experience is very specific and niche. Some videos feel like you have a dream world as a reference. If devs could pursue all of what you describe, then they wouldn't be coding. If you are building a small system, then yeah what you say makes sense. If the system is part of a much bigger system then if everytone did what they discovered it would never work. And those are the easy picks I have on your argumentation. Most developers I've met, there are not competent enough or just don't care to do what you describe and this makes the title of the argument valid. Dev jobs are what doctors jobs used to be in the past. A dollar making job, which many will pursuit for the money and funny thing is that there is so much demand, there is so little risk (people don't die) that the workforce is not capable performing what you say. Have you seen the hiring process? Stepping out of your code requires to a certain point other skills as well. You can be the best coder but that doesn't mean you can enter architect or product owner territory, in a similar way that you can't do testing that well. The helicopter view is not easy, as easy as it may sometimes look. And then there is the business. They often do know, they can't make up their minds, they don't listen and they expect some sort of magic yesterday. Often this leads to going over the same things back and forth and despite the warnings, still actually doing this.
I work as a dev, architect and manager for almost 25years in two countries and have collaborated with devs from USA, India and many European nations. There is no way you haven't experienced this reality. I share your vision, the dream if you want, but trying to define a job role based on a dream is kind of misleading to the people who are looking for carreer information. I remember as well doing agile and all the nice things it said about devs being in control. I was also a scrum master and product owner. Hahahahaha. Yeah right. But business, managers and leadership in general have completely different ideas. And I can understand them. It's not that a customer will say, oh your devs are doing what I watched on the video, here you can take 6 months longer.
If you were lucky to work and collaborate in all dream locations, then good for you but the reality is not even near to this video.
If I go back to college years, I would learn how to make my employer make more money or save money. Anyway make that possible regardless of my "title" or "career." At the end of the day my employer won't give a s#I^ who I am as long as I have made it possible to make or save money to pay me.
Hi Dave! In your "Acceptance Testing | Webinar" you showed us a great strategy for independent test - such that when you createBook("Continuous delivery"), then in reallity it stores the book in the database as "Continuous delivery1234", to keep them separate. that's a very nice idea.
But I have a question, let's image I have a page with a list of books, and when I run tests in parallel, then that list of books shows many books named "Continuous delivery1234". How can I write tests for a page that lists books, if other tests add many books?
I haven't seen the video, but why do you have multiple tests creating books? If you're not testing that method and just need data to work with, you can create some books ahead of time (either with permanent seed data or at the start of the test group for those tests) or have some particular naming scheme particular to the test and making sure to clean up afterwards. There are various strategies bssed on your needs.
I've just realised that your logo is very similar but not the same as Captain Disillusion :)
SW development is inherently hard. That is why almost all SW developers have degrees. Treat them like the experts that they are.
You just explained in these 14 minutes why AI is NOT going to replace software developers (and, for that matter, good screenwriters) anytime soon. It's not that AI can't problem solve -- it's that AI can't problem solve creatively.
yup!
Nice t-shirt
The videos in this channel are really inspiring for me to let the people in our company and our clients know what to focus on.
But reading the comments on this channel and also parts of the videos here make me believe that the world of software development is still so very stuck in the past and people still do not understand what agile means.
Agile means agile. There.
We started working agile about 10 years ago and really struggled with how to implement all the rules of agile and scrum into our processes.
But you know what? There are no rules in agile. Be agile.
Try things and if they don't work for your company or your team, try something else.
Too many standups? Do less, or make them shorter. Sometimes a project just doesn't go well, so maybe do an extra standup and try to help each other.
This video in particular made me realize how well we do, apparently. Sometimes we let the product owner define the backlog. But if the tasks are too technical, we sometimes let a developer define the backlog.
During the backlog session however, we let the PO define the problem that should be solved, but often we tell the PO that that shouldn't be the problem to be solved at all. Hell, we often even redefine the stories during the backlog session, because whole new information arises.
Also, because of all the talking - which apparently a lot off programmers hate - we sometimes come to the conclusion that with a quick change in code, the PO (or someone else in the client's company) can do the rest of the work to solve the problem. That way the client saves money, or saves time for us to solve another task instead. Everybody happy.
lots of good points.... you should write/make to expand on this.
In my opinion, the videos often have an utopia as a reference. The reality is much different. In my opinion, the reason for the reality being so differemt and having such a mess is the fact that most software doesn't kill people, which is why it has attracted such a mix of skill and background. Would you like to drive over a bridge that is built by someone who hasn't studied engineering? Someone who doesn't understand the laws of physics? But you certainly use software that is built by people who have litle knowledge about the domain. People who make decisions with little knowledge. You see UXs that are a joke and wonder how is that possible? Did you play test this? And it's getting worse, everywhere where software becomes more dominant, like e.g. cars. I guess the soft part brings the best and the worse in an explosive mix. But thinking there is only the best, is dreaming and to a certain point misleading.
I agree with what you are saying, but I was annoyed by the extra long waffle at the beginning. If you want to produce good videos, get down to business fast and cut the crap. You can't tell someone to like something, especially before they have watched it.
Second point is, you really need to talk to the idiots who face the programmers when looking for jobs. I see a list of some ten or more languages, operating systems, libraries and other acronyms laid out like buzzwords with no bloody idea what they are trying to produce. Software can produce just about anything, and whether you think you will be any good for them is a matter of what kind of programming they want. I prefer to write in C these days as writing code in about ten languages simultaneously is only something a madman would do. It would confuse the hell out of you, so with corporate jobs, surely you don't change the language every 5 minutes. Like what Adam Smith was saying about division of labour. Your issue seem to come from a faulty recruitment process. You get what you ask for. I've got to say the number one reason I have not bothered replying to a job ad is this thing that the recruiter has not got a clue what they are talking about, like Chinese whispers I suppose.
Anyhow I know the software is done badly. We get to see it on all of these websites that are the product of British firms. I had some fun with the Farnell website. It asked specifically for a password with non alphanumeric characters. I use a *, but the * in the password crashed the web server for several hours. I tried to log in again and it crashed it the following day. Each time they had it back up and running again I could knock the entire system out lol. In the end I placed the order with another firm.
The hiring process is seriously at fault. Most recruiters have no clue what the people they are looking for do. They use all this fancy words about passion etc but literally it's a sales job and internally the terms used are all from sales and the incentives are also sales driven. I've met recruiters who were travel agents, retail shop empoyees etc. I've been to interviews that I had to explain to the recruiter what they were looking for. I've been to interviews where language compatibility was a problem to begin with.
But isn’t there value in knowing timelines? Even construction or manufacturing is hard with many problems to be solved (similar to his case for software development) but can we do without knowing how much something would cost or time it would take to build?
I am willing to be enlightened if I am misunderstanding his argument.
I think Farley has videos on estimates which cover this exact question.
continuous improvement
I hold the view that other than a CEO and a programmer, no other role int his industry is well defined, understood or has a strong consensus view formed around it, now you say that even a developer's role - is that different to a job - is muddy.....
if i may, the comments on your videos are pretty intelligent, a rarity on yt.
I agree that developer can be more than some mindless ribosome and able to creatively self-deliver out of the box protein much needed by the organism. however for a reason, nature herself decides to create majority of ribosome to be mindless and to become part of bigger mechanism that works well.
by the way, wouldn't it wonderful if we can interface with AI to create full software program free from bugs?
As much as I agree to this, larger organizations just can't sustain this. It's great for small projects but when you have a revolving door of people, limited resources and time, you will need scope and accountability which only an organized team structure can provide.
I really like your shirt 🙂
I realised that I am not a developer but programmer
Part of the reason is the "programmer culture". Since they start dress and act like kids, they are of course treated as kids. How can a man put dozens of coca cola cans in his shelf and be proud of it? Why does he wear a hoodie in the office and a worn T-shirt? Taking his useless "cool" tech gadges to work? And beside that there are no team culture to speak of. The developer doesnt want help when offered (to not loose face and appear incompetent), but also dont want to help his team mates (since he is "busy").
@@mdesnica”dressing like kids” is just your projection. Programmers don’t care. Programmers not cooperating is something completely different. Yes, programmers should cooperate.
😢
I have noticed that a lot of developers are just into development because of their coding skills rather than the interest in understanding and building a product. This is noticeable in how there is a demand for backend developers that are divorced from the concerns a the user's perspective. What is a problem then? Just a part of your code doing something for someone undefined whose shoes you will never wear. I have also started thinking whether or not the complexity of software development, and the lack of personal motivation to learning and exploring, is affecting the industry to a high degree. Especially now when companies are trying to change culture to be more innovative and also collaborative. What about women?
The problem is a complex task to be solved. In itself, it is neither pleasant nor unpleasant; our attached feelings are learned.
Things do not change by renaming them and searching for another word that currently has a pleasant effect; we just lose a new word over time.
Support comment, please ignore
i think coding is the hard part, one of many hard parts that need to come together.
the problem with thinking that coding is the easy part is when you're the developer and you see the design for the first time ever a week before launch.
Is this geared only towards junior positions? Mr. Farley is being captain obvious, software development is what he says it is, most of us know that. There's no need to explain the obvious, those who don't get it, shouldn't really be in this. I've been writing code for over 30 years, I want some interesting and controversial content.
My point is that while I think that most experienced developers would agree with what I say, almost no sw dev companies work like that. So it may be obvious, yet we don't act on the obvious.