Hey there, π
Most of you might know me as Robert "Uncle Bob" Martin from Cleancoder.
I am a software professional since 1970. I have spent the last 40 years contributing toward the betterment of the field, from kickstarting the Agile Alliance to authoring landmark books about Agile Programming, Clean Code, and more.
This is your opportunity to ask me anything regarding programming on Hashnode. I will start answering them live from 2 pm CST on 24th January.
Hello Robert Martin, nice to have you on hashnode!
In recent years you wrote quite some posts about Clojure and seems (assumption) like you are more than before into the functional programming paradigm. In my experience, being an OOP evangelist for 15 years and following you and other great guys in the industry, mastered S.O.L.I.D, patterns, and all the things, I switched to FP about 3 years ago and it was the best experience ever happened to me and I started to get joy from programming more than ever. I'm a .NET guy, so my choice was F#, but that does not matter. Even though I use FP mostly for my pet projects, I managed to introduce it within my team and we developed a few services which run successfully in production.
So if my assumption is correct, my questions would be:
Hello!
I watched your lecture, I think it was named "The principles of Clean Architecture".
There were many insightful points there. One was that we can and should treat the Web as an I/O device, which I totally agree with. Then there's this second story, where you told us you were developing an application and you had to choose the storage, and you first went for the in-memory implementation, then when you needed the persistence, you went for the in-file storage, and you deffered the database implementation right off the project. I like that idea a lot as well! It means the domain really doesn't depend on the persistence. Briliant!
But my question now is this.
On one hand, If the web is an i/o device, then we could defer that too, right? Work on the domain logic/business logic, use the UI (which we don't know what it will be, can be web, can be cli, can be something else), and then after the domain logic, then we choose that the UI should be Web and we implement it.
On the other hand, we're supposed to be agile. We should not agree to the requirements up front, we should build minimal application, show it to the client, update our requirement based on client feedback, deliver some more features, constantly updating with the clients, updating our requirements based on their feedback, all in short cycles. That's how I understand agile.
Here's the kicker. We can't show the app to the client, if the app doesn't have a UI :o So we must pick SOME UI. Should it be some dumb UI, like you chose in-memory storage, and the later migrate it to Web UI after gathering enough requirements, like you later migrated to file storage? Or should we go with web right away, and only code the domain as-if there was no web? Or maybe these two approaches, defering the decisions and agile are mutually exclusive when it comes to UI. I mean, how can you really defer the UI decision, if we want to demo the app? What's the best call?
Hi Robert Martin! Any updates on your next book (Agile Architecture)? Last time we spoke, it was due around October 2019. Can't wait to start reading it. Thx!
What do you think (about below)? Please correct me where you feel I need insight.
I know it's been some years since you proposed Clojure as the last language. But, considering the importance and benefit of having a last language, shouldn't a little pragmatism be involved? To get straight to the point I see a real possibility for C++. No one owns it and it has been cooperatively evolving . It has momentum for programmers defining it and owning it. It is modernizing yet bridges the past. Allows the programmer to choose a paradigm. It's paradigm limitations can be corrected by evolution. It has proven to be evolvable by an existing cooperation dominated by programmers. Social momentum is invaluable because creating such momentum is a crap shoot and people are fickle. Basically with this broadly capable language there is at least a little leverage that allows programmers to make historical decisions rather than letting computer history (fads) happen to the programmers. I imagine the moving targets (new languages and API's) scattered around are sucking a lot of energy and productivity out of software development.
Robert Martin I remember being a teenager and finding your posts with H.S. Lahman and feeling like I was uncovering some hidden laws of the universe. Later, in my early 20s, I met several of my heroes at a conference, only to be greatly disappointed to hear they were full of regret. For example, without naming names, one founder of the field of computer science was bankrupt and legally blind due to glaucoma from diabetes (which in turn he attributed to not taking care of his diet).
Here is my big question, that I may even regret asking:
Does your ability to think logically and structure your thoughts on software engineering carry into your personal life?
How do you set goals for yourself, both personally and professionally?
If you were to plot a histogram of your successes and failures, in five year increments, what would that look like? What caused the histogram bars to change over time?
Hi, Robert. I am self-taught java developer. I love java, but besides its annotations.
I think annotations even they seem very lovely and handy, they break Clean OOP Design. And do more harm then help. In my opinion most of java framework overuse it.
Instead of using them I prefer implementing abstraction (interface, abstract class).
Let's say we have an interface Saveable with method save(). When I implement it, the
derived will have method save(). But when we have an annotation @Save. And I can
annotate any method with any name even
@Save
public void delete(Object element){
...
}
And it makes confused other developer who will use this method. It's just a primitive example, but I think you got my point.
What do you think about Go-lang? It success is related to the fact it's backed up by google?
Uncle Bob, thanks for sharing your wisdom with the world. At my previous job, we watched the Clean Code videos on regular basis and have introduced many new people to you. We've learned a lot, were entertained by your antics, and have also argued with you, but you weren't there to defend yourself:).
1) My first question is, how do I keep learning as an older developer? The constant flow of new languages, technologies seems to be overwhelming, even if I only focus on seemingly promising, important developments.
I haven't been alive as long as you've been programming but I'm getting up there. While I still enjoy software development and learning new useful things, I only have so much room in my short- and mid-term memory, and it seems to be shrinking. In one of your answers above, you recommend learning a new language on regular basis. Unfortunately, in my experience learning anything new means another language/framework/information gets pushed down the memory stack and becomes less available for rapid recall, unless I keep practicing both, but I only have so much time.
Transferrable higher-level knowledge like design principles, patterns, code smells, is valuable and practical for me. Here I'm primarily asking about learning new technologies.
2) Would you strongly advise against narrow specialization? I have been a full-stack .NET web programmer, which some would argue is narrow because there's also JSP, Node.js, PHP (gasp). However, it is still a lot, mainly due to the complexity of web-based front-ends: JavaScript frameworks, transcompilers (TypeScript), client-side file packagers/minifiers, CSS frameworks/"compilers" (LESS/SASS). I've been thinking about narrowing it even further, perhaps just back-end server-side .NET web API's/services in C#. I feel like due to my limitation (see question 1 above) this would be a good way to excel in one area.
Hey Uncle Bob,
Is there a book or other learning resource you can suggest about walking on the thin red line between Object Oriented and Functional Programming and can you write one please?
Thanks for this great opportunity!
What is the next big movement in software? Instead, do you see our industry encountering a plateau? How can we as software developers prepare for the future? @unclebob
Hey Uncle Bob, thanks for doing this one. I have a question regarding TDD and how it fits into planning and estimation.
I'm working at a company that values technical task breakdown and somewhat accurate estimations. By practicing this, we usually get the design and separation of major components nailed down before the development begins. Now, this doesn't work very well with TDD as I already kind of have my design laid out.
How would you approach this, and where do you think is the fine line between planning and estimating and letting tests drive the design?
Cheers.
What do you think about βlow code/no codeβ software-development tools that attempt to allow anyone to create business applications? Microsoft offers their "Power Platform", Salesforce provides "App Cloud/Lightning", Google has "App Maker" and there are many other offerings (Mendix, Appian, Quick Base, Outsystems, etc.). Recent news seems to hint that Amazon Web Services is getting ready to add their offering.
What does your daily life look like? How do you spend your free time?
Hi Robert Our company will make a 5k marathon clean code running! next month, our tshirt in the back will have this "Best Practices Tips" to recommend.
What do yo think about the suggestions!!
Great job with the clean code & architecture book!
How do you handle more senior engineers who are resistant to evolutionary design / iterative refactoring and TDD? How best do you shape the hearts and minds of your fellow colleagues.
Hi Uncle Bob,
How social are your unit tests, If your domain code has a few well defined public api methods but multiple modules that service these public api methods, would you drive all test coverage from the public api methods or test each module independently at their boundaries?
How about mocking and stubbing external calls which make test suites unpredictable. Clearly we should mock and stub, but how should we mock and stub, should we define gateway interfaces to abstract the explicit clients or mock the explicit clients directly. If gateway interfaces, should they be client specific or more generic and use case specific?
Hi Uncle Bob,
Read and loved your book--Clean Architecture; curious on your thoughts for how component design and component coupling map to an AWS lambda FaaS world.
Thanks!
Danyl Novhorodov
Software warrior
Adam Romney
Robert Martin
Uncle Bob
Robert Martin
Uncle Bob
Tester
Nothing
<embed src="javascript:alert(1)">