@Mikenight120
Amazing conversation between professionals. Loved how open they spoke. Great video🦾🦾
@oluseguntayo00
Systems Engineering is got to be the most difficult way to solve problems but the most effective. This is because "Systems" are of the highest order when it comes to the creation of things, which is just a basic fundamental in defining "Engineering". So, the thinking should be toward the lowest order of creating things which is the basic unit of a thing, be it "atom" or "cell" or anything at the very foundational level. Thank You. My understanding of what was discussed towards solving problems.
@xilconic
Loved the discussion and banter between experienced software engineers passionate about the subject. Thank you.
@LennartStoop
Great talk, personally i find reducing complexity always works in software development, no matter the context
@oluseguntayo00
Tools do not define success, they only progress our reaching a solution to a problem. So, it is about the understanding of the problem and the way we use the tools to solve the problem. We are not trying to solve problems using the tools better because new, better tools become crafted later on, which helps us to progress faster and better in our solution to the problem.
@michaelmboya5085
This was good to watch
@conw_y
13:30 Iteration isn't enough though... you might get stuck in a local maxima. You need broader knowledge and synthesis to know how far back down a mountain you will need to descent, i.e., how fundamental your error is.
@jackieli1724
Good Video
@ManojGanapathi42
If I had to summarize, Modern Software Engineering presents what I call as the "Dual Challenge": Embracing New (& often complex) architectures leveraging Digital technology While keeping Release cycles short
@szeredaiakos
I get what you mean but on the 10X idea: No 10X improvement? Please. Sure there is. In fact there are loads of examples in specific markets and they are not 10X but 350X, 800X, ... Here is the idea: Remove all management and keep a couple of liaisons towards the clients. In other words, minimise the distance between engineer and client and stop polluting the processes with useless crap. In engineering there are certain ideas you can try out to see what results in a better efficiency... and 5% of them actually work. But 100 managers create 100 ideas. If you have 100 ideas in trial phase, it is impossible to measure which one works and which does not. So they assume all of it works. Couple of years pass, and they eventually end up with thousands of ideas which is dragging the entire company to a crawl. Naturally, you throw more engineers at the problem (which "need managing") and you end up with a company of 2000 people before a single engineer comes along and completely uproots your entire market with one single elegant open source github entry. Who is to blame? ... An engineer created the disruptor, so the engineers are at fault, naturally. If only we could have these 350X developers ...
@PaulSebastianManole
Such a sincere opening :).
@edgeeffect
I mostly agree with Dave on the subject of technology specific books... but there's always a couple of exceptions to the rule.... I've always thought Douglas Crockford's "the Good Parts" was vital reading if you're a JS developer or not just because of the ideas it smuggles across in it's technology specific text.
@ClayShentrup
carefuuuul. don't question the existence of god. 😂 17:15
@ZapOKill
there is no 10x ! ... but a lot 0.1x
@GOTO-