I agree with this video. I would add that a lot of the projects software engineers are tasked with is breaking up monolithic solutions into smaller pieces. So not only do you have to be 'good' at building things up in small iterations, you have to get 'good' at breaking things up into small pieces - while keeping the solution running.
Keeping it running is more like being a software EMT than being a software engineer. From an engineering standpoint, the system might need an outright transplant, but the need to keep it running means management will only approve a quadruple bypass.
On the one side, it’s really refreshing to listen to a real leading engineer like you. On the other side, it feels so sad to work with so many people in the industry, that have shiny roles like “Head of this and that” that don’t get even the basics of professional engineering and system design.
You're videos have helped me in ways I didn't think possible. I've worked in web design (bit of development) for a long time and the concepts I've learned improved the work that I do. The simple step of breaking tasks into small individual chunks (small business) empowers not only my work, but also the communicating with the stakeholders. They also feel empowered and in control of a project that don't really understand.
15:00 A good analogy for this concept is a library and a landfill. For a book to be read, it has to be easily discoverable. For the book’s content to be internalized, it has to be easy to read. The Dewey Decimal System makes the book easily discoverable. When the book includes a table of contents, familiar language, good grammar, coherent thoughts and a clear objective, it is easier to read. Books that wind up in the landfill probably weren’t worth the read and aren’t worth discovering. They could be full of great information but are difficult to comprehend and practically useless. Software Projects are the same idea as iterating on and publishing books. It is easy to edit a book that is well written, comprehensible, and has a defined objective; hard to iterate on a book that is written in gibberish that nobody understands and has no purpose.
A book non quantum field theory is neither easily discoverable for the average reader (it won't be in the local library), nor will it be even borderline readable. According to you it should end up on the landfill. Maybe you want to refine your quality criteria a little bit.
@@lepidoptera9337 In this analogy “landfill” is meant to be a metaphor for forgotten or lost knowledge/work. In a software project, you can’t reuse a library or method if you can’t find it or understand it. You bring up a good point though that for many things, specialized knowledge is required to even begin to ingest the material. Even then, it has to be well written for the sub-population that has a chance at understanding it.
@@haseebs.7286 Point is that most information is useless to most people and extremely valuable to those who know how to use it. I am sure we have a wonderful collection of Persian poetry... but since I don't speak the language I will never be able to experience it. You are correct, that same phenomenon also hits software reuse hard. Most libraries are not nearly as reusable as their authors were most likely hoping for. Often it is little things like language bindings... and even externalities like the license terms. A great example of reuse are the Python libraries. The "batteries included" concept works. The lower the threshold for the user, the more likely that the code will be reused.
I gave myself early Christmas gifts from Amazon: Continuous Delivery, Modern Software Development and Continuous Delivery Pipelines. Thank you for your work! Stay safe.
Totally buying your book. It's currently #4 on Amazon in the software category, right behind some O'Reilly titles. Maybe someday you could sign it for me.
Always interesting hearing about how software is re-learning how engineering works, and where the dead bodies lie in one's particular discipline (the things that make designs 'fragile' in that discipline/area..)
Hi dave, your channels is one of the best in UA-cam, thank you for doing free videos. I want to buy a physical copy of your new book as soon as its available again. Nice shirt btw
Great video! But I've been wondering how do you tie software engineering with your SDLC (say Scrum, Kanban or even Waterfall)? How do you relate them. I always seen discussions on either software engineering practices or a SDLC concepts, but never seen anything were someone tries to tie them together. Probably a 50 thousand foot level thing. Would it even been helpful to do that? I'm not sure.
haha it mean nothing to me. The problem is people these day word "agile" . But forgeting to build the structure base . If you don't have at , you just keep hiring more staff doing the same thing again2 .
Engineering for me is getting most out of the constraints physics is imposing on reality. In software creation we are so detached from real world physics, that Software Engineering needs to set proper constraints first. Though this might be a rather modern need as in the past the hardware itself served as constraining factor.
You are detached from the physical world? So the 24h day and the speed with which your fingers can type don't count? Lucky for you, that is exactly how your boss thinks about his underlings. :-)
@@lepidoptera9337 What's the implemented loc/coder/day rate in your organisation ;-) There a confusion between innovation/design, and it's implementation in most discussions.
@@philipoakley5498 Thankfully my organization is a one man shop, so all I have to care about is that I finish my own projects. While I used to work with project managers on science projects, we had rules of twos and threes, though. It always takes twice as long and costs three times as much as the naive first estimate suggests. :-)
@@lepidoptera9337 "rules of twos and threes" !!! yay, so true. The naive estimates are just the direct parts, the rest is the indirect (un-estimated) aspects.
Ok, I'm into chapter 2 of your latest book and I love it. Do you have a `Knuthesque` compensation scheme for errata identification, I've found one worth a cent in my ebook version: at the end of **Engineering != Code** section in the sidebar the middle of Fred Brooks quote `...he ` should be `... the` FWIW I always liken the scientific (and engineering) process to that of long division: You could do a precursory step of rounding off the two numbers in question first (just to make sure that you final answers are in the ballpark) then use the following algorithm: take a guess at how many times the denominator can divide the numerator by check how close you are stop when you have a good enough answer (in engineering) or a better answer than everybody else (in science)
I like the idea of the errata compensation, I think I will allocate the funds for each find to a charity. I have added £1 (given inflation) to the fund for your find, thank you. I really like your division example and may steal that, thanks again.
@Dave Farley do you discuss these architectural software design choices in your new book? I bought it and can't wait to read it. I want to learn more about good framework methodologies in software, so if your book doesn't cover this can you recommend another one? Thank you.
I’m 21 and I have finally decided the path of software developer. I’m currently working to change my major and dive into IT. And I’m planning on going to a boot camp in the future. Any advise is appreciated. Thanks in advance.
I have a few videos with advice that is meant to help people starting out, so you could take a look there: On Interviews - ua-cam.com/video/osnOY5zgdMI/v-deo.html Getting started with TDD: ua-cam.com/video/yfP_v6qCdcs/v-deo.html 101 Tips for New Developers: ua-cam.com/video/hjIlTaAMsbI/v-deo.html There's a lot more that you may find interesting on the channel, but I hope these are helpful.
Unless you are a nerd with very low EQ that prevents you from interacting favorably with people, I would suggest that you go into a different profession. Take it from a nerd with very low EQ. You have been warned.
whats the difference between modularity and separation of concerns? reuse? and for that matter, isnt separation of concerns and loosely coupled the same thing??
They are closely related, but not the same. My new book describes what I mean and why I think the division matters. I can have a module that does three things, that is not a separation of concerns. I can have code where the concerns of storage are separated from the biz logic, but are tightly-coupled. So no, they aren't the same.
How many versions of the same product are you going to release? 18? In that case you need reuse. If you don't, then reuse is of absolutely no concern. It will weigh you down and you will never ship a product. Separation of concerns has to do with the structure of your problem (data entry, data storage, filters, search, output generation). Can it be factored into the completely independent solution of partial problem? Modularity is an implementation strategy. Even if your problem factors, the single solution may still require too much code to be implemented monolithically and you have to break it up into loosely coupled modules.
Buying the electronic version is even better. It can't either away and will always be instantly accessible. All you need now is the dedication to read it :)
The biggest sin should be calling software engineers "coders". Software engineering, heck even programming, entails much more than coding. Thinking of oneself as a coder puts a person in the wrong mindset and they'll think their job is just to write code.
@jeff pentagon I know you are joking. Though it's a bit harsh, if you are just coding, you are not a software engineer and don't understand what engineering is.
a bit diff . Coder /code monkey deal with tech so on. Which end user doesn't understand a thing. Actually most of them is under appreciated . But these day with lack of budget , a coder can be a designer / system analyst. / senior engineer . A big job responsibility but never ever people appreciated it. Usually coder don't like to meet people , while some does like me doing all sort of cum before.
Headsup: sts, I'm not criticizing you, my message is sort of trying to compliment yours. Anyone who CANNOT proof my product or principle that their software works, they may not be calling themselves engineers. To be an engineer means you HAVE to apply the principles of engineering. Otherwise you're an engineer in name only. Now that we have this base condition classified; how can you have the wrong mindset if the actual evidence of success or failure is directly explainable? It is if you understand the engineering principles for software. There is NO exception to this rule; if it is expressible you can analyze it with engineering principles. Someone whos mindset is that they're not engineer is probably correct; Then they should just be writing code. You may argue that someone with a lot of experience and trial and error experience can be applying engineering through experience but the problem is that you cannot dissect deviations because you're missing effective methods to process deviating results (deviating compared to your experiences). Engineers using principles do not have this problem. Someone who gains experience by exception only cannot be an engineer. To be an engineer means to apply logical principles which always proof themselves. If you're in constant doubt of what your code does, you're not applying logic needed to be an engineer. You may call yourself a developer though. PS: One fundamental detail: At least in my country its illegal to call yourself an engineer without a degree that proofs you can apply the logic of engineering. So there's also a strict line that coders may not call themselves software engineers. To call software engineers coders, would be the same in terms of level as saying that physics school teachers are the same as theoretical physicists. The area where the two work is just dramatically different and require different set of skills.
I don't think that there are any reasons why not in terms of skills and learning. It is possible that you may face some difficulties getting your first job because of your age. In my experience the tech industry is not very used to older, but less experienced people, so you will probably be an outlier, but these days there are also lots of ways of finding work online, where that wouldn't be a problem. Good luck.
I take a lot of ideas out of this video. And (correct me if I'm wrong) I do feel that there is something critical and difficult to measure about the ability to "train" a critical thinking that doesn't interfere with the ability to see and comprehend the global image
Great video but I must say that while I appreciate the style, I disagree with the substance with your t-shirt. It's ambiguous whether life, the universe, and everything is referring to a union or an intersection. 😁
Best channel on youtube.
pen and paper helped me a lot.
it still does.
i just write and draw about the problem or design when i stuck.
it really helps.
I've always felt that a good coding session often reminded me of the scientific method. Glad to see I'm not alone in this.
I agree with this video. I would add that a lot of the projects software engineers are tasked with is breaking up monolithic solutions into smaller pieces. So not only do you have to be 'good' at building things up in small iterations, you have to get 'good' at breaking things up into small pieces - while keeping the solution running.
Keeping it running is more like being a software EMT than being a software engineer. From an engineering standpoint, the system might need an outright transplant, but the need to keep it running means management will only approve a quadruple bypass.
I am deeply impressed that you can talk for so long in front of the camera without jump cuts and almost completely without hiccups!
On the one side, it’s really refreshing to listen to a real leading engineer like you.
On the other side, it feels so sad to work with so many people in the industry, that have shiny roles like “Head of this and that” that don’t get even the basics of professional engineering and system design.
You're videos have helped me in ways I didn't think possible. I've worked in web design (bit of development) for a long time and the concepts I've learned improved the work that I do. The simple step of breaking tasks into small individual chunks (small business) empowers not only my work, but also the communicating with the stakeholders. They also feel empowered and in control of a project that don't really understand.
15:00 A good analogy for this concept is a library and a landfill.
For a book to be read, it has to be easily discoverable. For the book’s content to be internalized, it has to be easy to read. The Dewey Decimal System makes the book easily discoverable. When the book includes a table of contents, familiar language, good grammar, coherent thoughts and a clear objective, it is easier to read.
Books that wind up in the landfill probably weren’t worth the read and aren’t worth discovering. They could be full of great information but are difficult to comprehend and practically useless.
Software Projects are the same idea as iterating on and publishing books. It is easy to edit a book that is well written, comprehensible, and has a defined objective; hard to iterate on a book that is written in gibberish that nobody understands and has no purpose.
A book non quantum field theory is neither easily discoverable for the average reader (it won't be in the local library), nor will it be even borderline readable. According to you it should end up on the landfill. Maybe you want to refine your quality criteria a little bit.
@@lepidoptera9337 In this analogy “landfill” is meant to be a metaphor for forgotten or lost knowledge/work.
In a software project, you can’t reuse a library or method if you can’t find it or understand it.
You bring up a good point though that for many things, specialized knowledge is required to even begin to ingest the material. Even then, it has to be well written for the sub-population that has a chance at understanding it.
@@haseebs.7286 Point is that most information is useless to most people and extremely valuable to those who know how to use it. I am sure we have a wonderful collection of Persian poetry... but since I don't speak the language I will never be able to experience it.
You are correct, that same phenomenon also hits software reuse hard. Most libraries are not nearly as reusable as their authors were most likely hoping for. Often it is little things like language bindings... and even externalities like the license terms.
A great example of reuse are the Python libraries. The "batteries included" concept works. The lower the threshold for the user, the more likely that the code will be reused.
Your videos are a great way to start a day of coding.
Gets my head in the right place.
That's great to hear! Thanks!
I gave myself early Christmas gifts from Amazon: Continuous Delivery, Modern Software Development and Continuous Delivery Pipelines.
Thank you for your work! Stay safe.
Thank you for your support!
Totally buying your book. It's currently #4 on Amazon in the software category, right behind some O'Reilly titles. Maybe someday you could sign it for me.
You sir, honors our profession, thank you! Totally buying your book.
You always have the best t-shirts!
Always interesting hearing about how software is re-learning how engineering works, and where the dead bodies lie in one's particular discipline (the things that make designs 'fragile' in that discipline/area..)
Great summary of your Modern Software Development book. Great work 👏
Glad you liked it!
Another great video, thanks. The book is now top-most on my reading list.
You almost made me cry when talking about the messy code in minute 16. I fight against that coding "style" every day.
We're building an engineering shop from scratch. Continuous Delivery will be a fundamental part of its DNA.
"I'm sure if you have been working in software development for any time you've seen those systems too"
What's worse, I've made them.
😂
Awesome content! Really insightful
Where do you get your shirts?! I need all of them
His book will be software engineering 101 one day...
Thanks 😊
Hi dave, your channels is one of the best in UA-cam, thank you for doing free videos. I want to buy a physical copy of your new book as soon as its available again.
Nice shirt btw
Thanks, I think that paper copies are out next week 🤞😁😎
Excellent video
This channel is about bringing the same story in as many variations as possible. Continuous Delivery on repeat.
Ah, you noticed my secret plan 🤣🤣
There is a good reason for that, it works better than anything else! 😁😎
Great video! But I've been wondering how do you tie software engineering with your SDLC (say Scrum, Kanban or even Waterfall)? How do you relate them. I always seen discussions on either software engineering practices or a SDLC concepts, but never seen anything were someone tries to tie them together. Probably a 50 thousand foot level thing. Would it even been helpful to do that? I'm not sure.
Well, it rules out some bad ones. Waterfall is not iterative or incremental, for example.
haha it mean nothing to me. The problem is people these day word "agile" . But forgeting to build the structure base . If you don't have at , you just keep hiring more staff doing the same thing again2 .
Engineering for me is getting most out of the constraints physics is imposing on reality. In software creation we are so detached from real world physics, that Software Engineering needs to set proper constraints first. Though this might be a rather modern need as in the past the hardware itself served as constraining factor.
Most software is applied logic (maths) and the misunderstanding of how humans (the real world constraint) work (or don't)!
You are detached from the physical world? So the 24h day and the speed with which your fingers can type don't count? Lucky for you, that is exactly how your boss thinks about his underlings. :-)
@@lepidoptera9337 What's the implemented loc/coder/day rate in your organisation ;-)
There a confusion between innovation/design, and it's implementation in most discussions.
@@philipoakley5498 Thankfully my organization is a one man shop, so all I have to care about is that I finish my own projects. While I used to work with project managers on science projects, we had rules of twos and threes, though. It always takes twice as long and costs three times as much as the naive first estimate suggests. :-)
@@lepidoptera9337 "rules of twos and threes" !!! yay, so true.
The naive estimates are just the direct parts, the rest is the indirect (un-estimated) aspects.
Ok, I'm into chapter 2 of your latest book and I love it.
Do you have a `Knuthesque` compensation scheme for errata identification, I've found one worth a cent in my ebook version:
at the end of **Engineering != Code** section in the sidebar the middle of Fred Brooks quote `...he ` should be `... the`
FWIW I always liken the scientific (and engineering) process to that of long division:
You could do a precursory step of rounding off the two numbers in question first (just to make sure that you final answers are in the ballpark) then use the following algorithm:
take a guess at how many times the denominator can divide the numerator by
check how close you are
stop when you have a good enough answer (in engineering) or a better answer than everybody else (in science)
I like the idea of the errata compensation, I think I will allocate the funds for each find to a charity. I have added £1 (given inflation) to the fund for your find, thank you.
I really like your division example and may steal that, thanks again.
@Dave Farley do you discuss these architectural software design choices in your new book? I bought it and can't wait to read it. I want to learn more about good framework methodologies in software, so if your book doesn't cover this can you recommend another one? Thank you.
I feel more like a composer than an engineer, although rust is getting me into high perf computing
I’m 21 and I have finally decided the path of software developer. I’m currently working to change my major and dive into IT. And I’m planning on going to a boot camp in the future. Any advise is appreciated.
Thanks in advance.
I have a few videos with advice that is meant to help people starting out, so you could take a look there:
On Interviews - ua-cam.com/video/osnOY5zgdMI/v-deo.html
Getting started with TDD: ua-cam.com/video/yfP_v6qCdcs/v-deo.html
101 Tips for New Developers: ua-cam.com/video/hjIlTaAMsbI/v-deo.html
There's a lot more that you may find interesting on the channel, but I hope these are helpful.
Unless you are a nerd with very low EQ that prevents you from interacting favorably with people, I would suggest that you go into a different profession. Take it from a nerd with very low EQ. You have been warned.
That T-shirt... :-)
whats the difference between modularity and separation of concerns? reuse? and for that matter, isnt separation of concerns and loosely coupled the same thing??
They are closely related, but not the same. My new book describes what I mean and why I think the division matters. I can have a module that does three things, that is not a separation of concerns. I can have code where the concerns of storage are separated from the biz logic, but are tightly-coupled. So no, they aren't the same.
How many versions of the same product are you going to release? 18? In that case you need reuse. If you don't, then reuse is of absolutely no concern. It will weigh you down and you will never ship a product. Separation of concerns has to do with the structure of your problem (data entry, data storage, filters, search, output generation). Can it be factored into the completely independent solution of partial problem? Modularity is an implementation strategy. Even if your problem factors, the single solution may still require too much code to be implemented monolithically and you have to break it up into loosely coupled modules.
Twist my arm into buying your book!
(but I wimped out and bought the electronic version)
Buying the electronic version is even better. It can't either away and will always be instantly accessible.
All you need now is the dedication to read it :)
The biggest sin should be calling software engineers "coders". Software engineering, heck even programming, entails much more than coding. Thinking of oneself as a coder puts a person in the wrong mindset and they'll think their job is just to write code.
@jeff pentagon I know you are joking. Though it's a bit harsh, if you are just coding, you are not a software engineer and don't understand what engineering is.
a bit diff . Coder /code monkey deal with tech so on. Which end user doesn't understand a thing. Actually most of them is under appreciated . But these day with lack of budget , a coder can be a designer / system analyst. / senior engineer . A big job responsibility but never ever people appreciated it. Usually coder don't like to meet people , while some does like me doing all sort of cum before.
Headsup: sts, I'm not criticizing you, my message is sort of trying to compliment yours.
Anyone who CANNOT proof my product or principle that their software works, they may not be calling themselves engineers. To be an engineer means you HAVE to apply the principles of engineering. Otherwise you're an engineer in name only.
Now that we have this base condition classified; how can you have the wrong mindset if the actual evidence of success or failure is directly explainable? It is if you understand the engineering principles for software. There is NO exception to this rule; if it is expressible you can analyze it with engineering principles.
Someone whos mindset is that they're not engineer is probably correct; Then they should just be writing code. You may argue that someone with a lot of experience and trial and error experience can be applying engineering through experience but the problem is that you cannot dissect deviations because you're missing effective methods to process deviating results (deviating compared to your experiences). Engineers using principles do not have this problem.
Someone who gains experience by exception only cannot be an engineer. To be an engineer means to apply logical principles which always proof themselves. If you're in constant doubt of what your code does, you're not applying logic needed to be an engineer. You may call yourself a developer though.
PS: One fundamental detail: At least in my country its illegal to call yourself an engineer without a degree that proofs you can apply the logic of engineering. So there's also a strict line that coders may not call themselves software engineers.
To call software engineers coders, would be the same in terms of level as saying that physics school teachers are the same as theoretical physicists. The area where the two work is just dramatically different and require different set of skills.
Is it realistic to become a Software Engineer if you're age 40? (I'm seriously considering it, now learning Python)
I don't think that there are any reasons why not in terms of skills and learning. It is possible that you may face some difficulties getting your first job because of your age. In my experience the tech industry is not very used to older, but less experienced people, so you will probably be an outlier, but these days there are also lots of ways of finding work online, where that wouldn't be a problem.
Good luck.
I liked before I watched.... dont let me down.
lmao
I take a lot of ideas out of this video. And (correct me if I'm wrong) I do feel that there is something critical and difficult to measure about the ability to "train" a critical thinking that doesn't interfere with the ability to see and comprehend the global image
Come to google books please!
Great video but I must say that while I appreciate the style, I disagree with the substance with your t-shirt. It's ambiguous whether life, the universe, and everything is referring to a union or an intersection. 😁
You may be reading too much into the shirt 🤣🤣