In this type of company it is the task of the architect(s) to establish a predictable and consistent environment and to provide access to it as easily as possible, both for technical and for business people. When onboarding, you will want to know where to start and you will want the company (your technical colleagues in this case) to provide a consistent and working environment for you. Who would not appreciate that as a developer and also as a software engineer? A "distributed" approach to this type of business is maybe not the best idea. To get away from that is obviously important to them. The "question" here is if a distributed approach of software development works, when everyone has their own tools and sub-architecture and when the company has a well-defined and limited type of product(s). It seems not to work for them in the long run, so this is an answer to be aware of before onboarding. To talk about pair programming is particularly interesting here. It gives you an idea of how "far" you can go with collaborating when it comes to systems and technical design challenges from the point of view of an "engineer" (if that is what you are or do) while being limited to a technical environment where these things are meant to be already provided for you ... what does it mean to you as a developer when onboarding? You will want to know the role you applied for, its advantages and limitations in that particular (type of) environment in advance. It can also be an advantage as a junior to learn to accept and respect your working environment and to see a technical architecture from "inside" while also learning the basic stuff first. Of course learning to collaborate and thinking should be included, at least this is what I think. But in any case, to be able to create working solutions yourself you might want to see some first and also you might want to see technical people taking care of that and how they do that, unless you are a true genius and these are extremly rare with the "IT industry" not being an exception. So this is really important stuff here.

Are there frameworks to manage calls across all the endpoints to get a view? Frameworks or custom code would need to fill the gap. The power of SQL is lost in micro services. 😮

Interesting he didn’t mention start by learning the business even before you actually learn the code. That’s what I would say.

I loved Spotify. But it was an abusive relationship. Now I'm on Apple Music. I think Spotify is a case study of how taking the thing that made you popular (the recommendation algorithm) can work against you if you keep trying to up the ante. When you have hundreds of people in the forums asking you FOR YEARS to add a true shuffle functionality to playlists and instead you take away the "enhance playlist" and force a new default shuffle mode onto every playlist that turns it into a radio station as a middle finger to people who want to enjoy human-made recommendations, maybe ego has replaced innovation at that point. Sure, make recommendations available to people who want them. But allow humans to pick and recommend songs without trying to sabotage them if they want that too. The best thing about Spotify, for me, were the Release Radar and Discover Weekly playlists. 60 new songs a week! Until the cancer of "every playlist must be a radio station" infected those too, and now you get 'some new songs and mostly repeats from previous weeks'. *shakes head* EDIT: I went to an artist and clicked to see the songs I had liked... it started inserting songs I was positive I detested and I was thinking "WHY DID I CLICK LIKE ON THAT?!" Starting trying to rationalize... maybe I was giving it a second chance? No... I was just being gaslit by Spotify's nonsense of the day. But they hid the button to see if you liked it or not, to further trick you. GIVE ME MY BIG OLD HEART BACK... They want you to have to click like 3 times to indicate you liked or disliked a song, even in 'car mode' to increase traffic accidents because they really are evil.

ask the developers not the sales people like this guy.most of all ask the develoeprs that left to get the truth. spotify is alway building a great product and has the best practices. in the end its all bs.

Usually, Mr. Farley's interviews are good. This time, they were talking for five minutes and saying nothing worth listening to - just the usual "it depends on what you do" spiel. Sorry to disappoint you.

Thank you for another informative session 🙏 Sharing far and wide.

Love your burgers my man

Business school grad here turned Software Engineer. Most B school grads have no coding experience, can’t do anything on a command line interface, they don’t know what a schema is, or what a json file is, what an API. They don’t know anything that a Software Engineer does. It doesn’t stop them from throwing buzz words like IT, Cloud, Agile, AI, Machine Learning, Data, API, cyber security, open source.

I am not understanding. Why not just code what you need to code to get the job done. Why are we fomalizing something that is intuitive?

Could you speak more about these fitness function ?

This is so true. My tech lead will branch out of my change and write the code her way. It got to the point where I had to just sit and watch.

Another brilliant video. Thanks Dave! Anyone got tips on how to determine if a company has this kind of culture when interviewing for a job with them?

I automated 10 outof 14 office worker jobs, once. They retired, i flipped a switch and integrated their work function.How do you measure the value if a coder?

Actually if systems are connected using a database, there's a simple way to decouple them - using views. If a dependency changes its schema, you can recreate the view with a new query underneath.

You've got to do a video on entropy next time. I'd like to hear your take on cohesion and proper use of words from a DDD standpoint. Words and language skills are kind of underestimated in software. They're really powerful in my opinion.

I don't have flaky tests, … because I'm the only one who writes tests at all! 😭

This is good advice. Especially where the emphasis is on identifying areas where tight coupling is called for. I've seen projects fall to excessive cross talk and tragedy of the commons due to an irrational fear of any coupling whatsoever. The good part is that tight coupling is typically obvious compared to the much more subtle work of maintaining proper loose coupling. Loose coupling requires good discipline, and the ability to wear many hats within a system in order to understand zones of ownership and concern, and formalizing hand off between systems and domains. Fear of coupling at the start inevitably leads to shortcuts later on, with do-everything systems trouncing service-level tables in databases, internal members or state, or otherwise deep intertwined logic from a lack of formal exchange mechanisms that selective tight coupling helps illuminate.

6:55 This is just plain wrong. You can call print from a lambda. I think you may have been confused because map is a generator, so just doing map won’t execute any code, you have to iterate over the map to have it run the lambda.

I think people get hung up on explicit assertions. Checking every little parameter or return value. You don't need to cover everything. Just just need to make sure that your main assertions are correct, and you can be implicit about the stuff that bothers you less.

I haven't been in environments that practice TDD. Most places have created tests after the fact. But I would like to use the TDD-approach, to be more explicit with what I build, even if the assertions are implicit. And this is probably why people see unit testing as cumbersome and a waste of time: They think that they have to be explicit down to the detail. But you don't have to. You just have to think about what you build, its behavior, and be less write, compile, run (ego trial and error without knowing what to achieve). On the fly programming.

Nice example with fractions. However real life is a little bit more complex. Imagine that you have to create a neural network that generates people images with exact 5 fingers. Good luck to write tests!

Metrics always "escape" to management.

I think Gojko has seen a lot and has more to say but time is a big constraint. I wonder how is like to work with him. I really like people discussing how things works under the hood instead the just it works kinda devs

De-Coupling, Strangler-Pattern, Microservice... is this just innuendo of some smart ass or do we have architectural patterns in social relationships or should I stop projecting?

Very informative 🧠

Over my career I have swung on both sides of this debate. I think there are elements of the industry that are arguably in the bracket - to be honest down in the system, near the hardware and similar embedded systems. However for most of us, I think craftsman (ignoring the lack of gender neutral name) really is more appropriate. Perhaps though it is our model of what a craftsman is that causes us to reject it. I think the nearest we are is to the medieval stonemasons who build cathedrals. There was a standard approach they could alter based on there own and "customer" preferences, as well as site specifics. They worked in teams - it was not a one or even two person operation. Basically there was heuristic knowledge of what (usually) worked and that most would follow. Every now and then, someone would have an idea on an improvement. Sometimes it worked. Generally what they built stayed up but it was based on experience. Compare to now where there would be architects who would design it but would consult structural engineers who would probably generate a model the system but least do lots of calculations based on scientific knowledge of the materials etc. Different engineers, with different skills, would actually build the thing. In our approach we are much nearer the medieval masons than the structural engineers.

It's FTSE all the way down

3:35 Who doesn't love stock videos, let's take a look at what is happening around 7th line from the bottom of the screen 👀😆

I came here to hear the words dependency injection/inversion. Let's see if I get my wish...

Thank you so much for this clear communication This is nothing short of brillant, extremely important and widely under appriciated

Did you ever read the classic Yourdon & Constantine's "Software Engineering"? He covers this issue, making it a point to avoid at all costs "pathological coupling".

I'm glad you're doing this video. I've been a programmer for almost 25 years and I just heard about Coupling and Cohesion a few months ago. It's so much better and simpler than S.O.L.I.D. principles that everyone raves about.

Great vid. Your REST API example serves as a sort of materialization of design by contract, which is very OK in my book. It also falls into Allan Kay's "message passing" view which, again, is very OK as far as I'm concerned. As far as the contract and the message is properly documented both sides can go on their merry way and do whatever they have to do on their side. And you can extend it without breaking it by simply adding more endpoints (or versions of). And if you think of it as simply a "boundary between components", you can extend the concept to anything. IMHO, this is where "classic OOP" does a great disservice by not saying that separating data from code is a GoodThingTM. FlowerData is all you can know about Flower. Flower receives FlowerData it can operate on (state). But both are distinct entities. DTO's are an "ashamed acknowledgement" of the fact, as all data can exist without behavior but not the other way around.

With innate motivation to build ood softwae, why is so much software pure garbage?

Can we get the full episodes on KZbin? Having KZbin premium and not having full podcast is a bit sad 😔

FREE 'How To Evolve Your Software Architecture' Guide: How to work in ways that keep stuff easy to change which gives you the freedom to make mistakes and experiment and how to work in small steps that allow you to determine their fit for your present understanding of the problem... continuously. All explained in this FREE compact guide. Download HERE ➡ www.subscribepage.com/evolve-your-architecture

I agree with some of his points but not sure why he would find the term accountable so offensive. Surely accountability is just about ensuring that everyone within the team is pulling their weight and working in alignment with the rest of the team? You can have a great team but if you have just one person who isn't accountable, doesn't really care or is often MIA then that will affect the whole team.

You simply cannot measure developer productivity by the number of lines of code written (aka. SLOC, which stands for Source Lines of Code). This metric results in developers gaming the system by writing inefficient code just to inflate their metrics. In the worst case, developers will duplicate procedures and introduce unique bugs into various copies of the code. I once inherited a code base written by 32 developers over the course of 3 years. It was a nightmare. The combined work made up the code for two desktop applications and a communications server that ran as a Windows NT service. Neither of the desktop applications had been successfully compiled in more than a year. To top it off, there were no formal design specifications. After noticing a few duplicated procedures which had different parameters and minor differences in the internal code, my next step was to analyze the code base. I discovered that the majority of procedures had been duplicated between 3 and 14 times. While the intent of each procedure was to perform the same function, the procedures had to be compared against each other to determine which one should be retained. Then all of the code referencing the retained procedures had to have the order of parameters aligned (and in some cases created). Of course, there was no standard convention for naming variables or objects. My manager complained after two weeks about my productivity. He was trying to measure me by SLOC while I was converting the code base to an object-oriented design and removing thousands of no longer needed lines of code per day. I will provide an example to explain how this was possible. One procedure contained 8 lines of code which were repeated so many times with only minor changes that it required 66 sheets of paper to print it to hardcopy. This was rewritten as a single function called in a loop to populate a linked list which held the results. This printed on less than a single sheet, but it didn't help the metrics I was being held to. Fortunately, the senior management and customers were very impressed when I delivered new applications featuring modern user interfaces that loaded data into a tree view from a relational database in less than one second (where the last version that would compile took more than 80 seconds) and a communications server that no longer thread locked after 255 calls. Over the next two months I added the complete backlog of features requested by customers. I measure developer productivity by the number of elements that users can see, the features in the business logic layer and data access layer that they can't, and by customer satisfaction. If the product doesn't meet customer expectations, then nothing else matters.

Fantastic video! Thanks for covering this Dave. Observability is so important and I've seen the benefits of this in production - before and after.

Preach!! 🙏

Great video !

I have to disagree mightily here.. Engineers have a thorough understanding of their area of knowledge from first principles and are primarily designers. Craftsmen have experience and a visceral feeling for their chosen medium and are primarily makers. Both are creative and innovative.. As a wise man once told me, anyone can understand how to lay bricks, few can lay them fast enough to make a living