This speaks volumes to how I have lived my software engineering career. I learned this from others along the way. Clearly, I was lucky. You are backing this learning up, and I thank you.
I think you nailed it when you said software engineering is about producing code that is easy to change. That's what we are paid for. Maintainability and testability are two sides of the same coin, it's the same thing.
A tragic and frustrating reality I've found is exactly this 👆 Make code easily maintainable and testable (even if you haven't fully written out all the tests). I suspect many contractors who only temporarily work on products fail: they're not maintaining it and don't learn how to make it more maintainable.
Thank YOU for producing this informative and helpful video. I’m a hobbyist with ambitions to produce some nice and desirable products commercially in the future and I will now make less mistakes along way. My path now has some more clear ideas to pursue to producing things that are actually good. Make no mistake though, I am now a little more aware of how far I still have to go.
Any dogmatic "best practices" would only make mediocre and hopefully competent programmers that can be easily replaced by other cogs and eventually AI. To be a great programmer, one needs to develop deep understanding and intuition of the problems they are trying to solve and be comfortable with various trade-offs given different constraints, which should be rigorously challenged with first principles. Yes, users and ops are part of the problems. Remember, no silver bullet.
I agree with you, I'd also add that, at least from my perspective, curiosity plays a huge role on become good at anything that you do. From my experience curiosity leads to passion which, if accompanied by dedication, will produce great results and you'll also feel satisfied
Shuhari. To reach the stage you are talking about requires putting the time in, using the "best practices", and getting the expertise to be able to judge what is and isn't effective. You don't teach a master the same thing you teach a novice. You can't jump to the final answer or you won't have the necessary foundations. If you try to skip the steps, you become an "expert beginner".
Intuition is my strong suit, i usually figure stuff out long before i can 'splain it. I have a strong suspicion that there is a lot of value just reasoning through stuff directly.
31:24 To be honest, in order to have that "dream team" you're talking about, you need to have a good test environment where things can be tested and be broken. I've worked in too many CI projects where the idea is that, whenever you have committed code it should be ready to go to production immediately. And therefore people are really anxious about what can allowed to even go into test, and therefore you always need two approves and lot of scrutiny before they are finally accepted, if it even is.
I love how you could cast a Bayesian interpretation of Continuous Integration quite easily. Feature branching seems like a less efficient way of finding a maximum in the posterior probability of code optimality.
15:40 I think what you mean here is that they are open to good ideas, whether its their own or others ideas. If they defend their idea, then that's because they believe it is better, but if you can illustrate a better idea in a logical way, they will accept it. The other side of the spectrum will be narcissists, they will accept their idea and only their idea.
I agree with readability, but nobody cares about it, smart people think that the more obscure, chainable or “efficient” the code the better and the business people don’t understand anything other than the number of features and delivery dates. Such is the nature of the game it seems.
Except that the way you get the "more features" that the biz people want, and write the "efficient code" that the devs want is to write readable code. For the biz people, because readable code is easier to change and making the code easier to change is how we go faster. For the devs, readable code is easier for compliers to parse and so optimise, easier for devs to understand and so easier to eliminate stupid performance mistakes. So everyone cares, they just don't know enough to know that they care 😉
I appreciate your perspective but I think you are dramatically underestimating the difficulty of changing a bad boss' mind about testing and refactoring.
not really, we all know how hard it is to fix bad attitudes in bosses. in the end it comes down to the question of which sort of bad boss you have. if it is someone who makes bad choices because they don't know any better, train them by ramming home the points they are missing at every oportinity until they start to get it. for example if they want to get a feature out the door quick, point out that by not letting you test, future changes will be slower. if they still don't let you test, point out that now it is done, we need to spend the time to test, and to get it right, or the next change will be slower. if they still did not let you test, when the next change comes along, point out how it will now take longer to do, as you still ha e to do all the work you were not allowed to do before, to get it into a shape where it is easy to add the new stuff. if after doing that for a while, there is still no willingness to let you test, then you have a black boss. with a black boss, their only interest is climbing the company ladder, and they will do anything to make themselves look good in the short term to get the promotion. the way to deal with this is simply to get a paper trail of every time you advise him of why something is a bad idea, and him forcing you to do it anyway. encourage your colleagues to do the same. eventually one of the inevitable failures will get looked into, and his constantly ignoring advice and trying to shift blame to other will come to light. in the worst case, you won't be able to put up with his crap any more, and will look for another job. when you do, make sure that you put all his behaviour in the resignation letter, and make sure copies go directly to hr and the ceo, who then will wonder what is going on and in a good company will look to find out.
@@jimhumelsine9187 I have seen this too but usually when you peel back a few layers the underlying problem is still management or product teams that apply pressure on the devs to cut corners. Occasionally you do run into the diva developer who thinks they are above testing but I think the more common excuse is "we don't have time" which really means "my manager is going to have a hissy fit if I tell him we should add a day to the estimate for writing tests".
@@jimhumelsine9187 because testing is not really taught, and people don't design with testing in mind, having to test the legacy code can be a pain, so some developers don't like it, but it still comes back to management. either the company cares about tests, or it does not, and if you do care, then everyone needs to write and not break tests. testing is like version control, it only works if everyone does it, and you cannot do continuous integration without it.
![Blox Fruits Dragon Rework Update [Full Stream]](http://i.ytimg.com/vi/EqDAp8udhm0/mqdefault.jpg)
This speaks volumes to how I have lived my software engineering career. I learned this from others along the way. Clearly, I was lucky. You are backing this learning up, and I thank you.
I think you nailed it when you said software engineering is about producing code that is easy to change. That's what we are paid for. Maintainability and testability are two sides of the same coin, it's the same thing.
A tragic and frustrating reality I've found is exactly this 👆 Make code easily maintainable and testable (even if you haven't fully written out all the tests). I suspect many contractors who only temporarily work on products fail: they're not maintaining it and don't learn how to make it more maintainable.
Thank YOU for producing this informative and helpful video. I’m a hobbyist with ambitions to produce some nice and desirable products commercially in the future and I will now make less mistakes along way. My path now has some more clear ideas to pursue to producing things that are actually good. Make no mistake though, I am now a little more aware of how far I still have to go.
I liked your promotion of Taking pride in a job well done, particularly in the grunge job that no-one wanted to do.
Listened all the way through, enjoyable content.
Any dogmatic "best practices" would only make mediocre and hopefully competent programmers that can be easily replaced by other cogs and eventually AI. To be a great programmer, one needs to develop deep understanding and intuition of the problems they are trying to solve and be comfortable with various trade-offs given different constraints, which should be rigorously challenged with first principles. Yes, users and ops are part of the problems. Remember, no silver bullet.
I agree with you, I'd also add that, at least from my perspective, curiosity plays a huge role on become good at anything that you do. From my experience curiosity leads to passion which, if accompanied by dedication, will produce great results and you'll also feel satisfied
Shuhari. To reach the stage you are talking about requires putting the time in, using the "best practices", and getting the expertise to be able to judge what is and isn't effective. You don't teach a master the same thing you teach a novice. You can't jump to the final answer or you won't have the necessary foundations. If you try to skip the steps, you become an "expert beginner".
True, but as in art, first you have to know the rules of your craft, then you have to know when to break them.
Intuition is my strong suit, i usually figure stuff out long before i can 'splain it. I have a strong suspicion that there is a lot of value just reasoning through stuff directly.
I would consider TDD to be excellent example of a "best practice"
31:24 To be honest, in order to have that "dream team" you're talking about, you need to have a good test environment where things can be tested and be broken. I've worked in too many CI projects where the idea is that, whenever you have committed code it should be ready to go to production immediately. And therefore people are really anxious about what can allowed to even go into test, and therefore you always need two approves and lot of scrutiny before they are finally accepted, if it even is.
I love how you could cast a Bayesian interpretation of Continuous Integration quite easily. Feature branching seems like a less efficient way of finding a maximum in the posterior probability of code optimality.
Donald Knuth - "Programs are for people to read and only incidentally for computers to run"
Thank you very much!
Diagram everything, when I got a whole game to work on I literally printed every file and went full CSI on it with strings, wires, etc.
the "your code doesn't work and you are a danger to others" made me crack up
15:40
I think what you mean here is that they are open to good ideas, whether its their own or others ideas.
If they defend their idea, then that's because they believe it is better, but if you can illustrate a better idea in a logical way, they will accept it.
The other side of the spectrum will be narcissists, they will accept their idea and only their idea.
I agree with readability, but nobody cares about it, smart people think that the more obscure, chainable or “efficient” the code the better and the business people don’t understand anything other than the number of features and delivery dates.
Such is the nature of the game it seems.
Except that the way you get the "more features" that the biz people want, and write the "efficient code" that the devs want is to write readable code.
For the biz people, because readable code is easier to change and making the code easier to change is how we go faster.
For the devs, readable code is easier for compliers to parse and so optimise, easier for devs to understand and so easier to eliminate stupid performance mistakes.
So everyone cares, they just don't know enough to know that they care 😉
People who think that are not smart.
@@zerettino Valuing obscurity, not smart. The other two, sometimes smart.
"Not my work, but similar" - imagine putting that on your LinkedIn profile or resume. Suss
I appreciate your perspective but I think you are dramatically underestimating the difficulty of changing a bad boss' mind about testing and refactoring.
not really, we all know how hard it is to fix bad attitudes in bosses.
in the end it comes down to the question of which sort of bad boss you have.
if it is someone who makes bad choices because they don't know any better, train them by ramming home the points they are missing at every oportinity until they start to get it.
for example if they want to get a feature out the door quick, point out that by not letting you test, future changes will be slower.
if they still don't let you test, point out that now it is done, we need to spend the time to test, and to get it right, or the next change will be slower.
if they still did not let you test, when the next change comes along, point out how it will now take longer to do, as you still ha e to do all the work you were not allowed to do before, to get it into a shape where it is easy to add the new stuff.
if after doing that for a while, there is still no willingness to let you test, then you have a black boss.
with a black boss, their only interest is climbing the company ladder, and they will do anything to make themselves look good in the short term to get the promotion. the way to deal with this is simply to get a paper trail of every time you advise him of why something is a bad idea, and him forcing you to do it anyway. encourage your colleagues to do the same. eventually one of the inevitable failures will get looked into, and his constantly ignoring advice and trying to shift blame to other will come to light.
in the worst case, you won't be able to put up with his crap any more, and will look for another job. when you do, make sure that you put all his behaviour in the resignation letter, and make sure copies go directly to hr and the ceo, who then will wonder what is going on and in a good company will look to find out.
In my experience, I witnessed more push back and reluctance about testing and refactoring from fellow developers than from management.
@@jimhumelsine9187 I have seen this too but usually when you peel back a few layers the underlying problem is still management or product teams that apply pressure on the devs to cut corners. Occasionally you do run into the diva developer who thinks they are above testing but I think the more common excuse is "we don't have time" which really means "my manager is going to have a hissy fit if I tell him we should add a day to the estimate for writing tests".
@@jimhumelsine9187 because testing is not really taught, and people don't design with testing in mind, having to test the legacy code can be a pain, so some developers don't like it, but it still comes back to management. either the company cares about tests, or it does not, and if you do care, then everyone needs to write and not break tests.
testing is like version control, it only works if everyone does it, and you cannot do continuous integration without it.
Your hobby might cut it 😯
the worlds dullest man
@@Gringohuevon You are not his audience. I am a senior software developer and for people like me, this is valuable content.