Once you get over the syntax and basics of writing a program, I would recommend learning about writing maintainable software.
Kent Beck's 4 rules of simple design is great. You can find the rules online.
Some great books are Clean Code, Pragmatic Programmer, Working Effectively with Legacy Code
I am glad the author meant the book Clean Code and not the concept.
Code Complete 2 by Steve McConnel
Clean Code by Robert Martin
Beautiful Code by Andy Ormen, Greg Wilson
Refactoring 2 by Martin Fowler
Clean Code - Robert Martin. <-- this is without a doubt the number one book to read in my opinion
Working With Legacy Code - Michael Feathers
I'm reading Clean Code at the moment.
I don't agree with everything.
I think it would be a mistake to take it on it's every recommendation.
Clean Code is good as well as anything by Bob Martin or Robert Fowler.
TLDR: Author recommends "A Philosophy of Software Design" over "Clean Code"
Domain Driven Design by Eric Evans
Implementing Domain Driven Design by Vaughn Vernon
Clean Code by Robert Martin
I think you will find some code in all of the books but the ideas are applicable almost everywhere.
It's from the guy who wrote Clean Code and Clean Coder which are gems themselves !
Clean Code by Robert C. Martin
This helped me break my analysis paralysis when it came to figuring out how to organize my code.
> these are soft-skill books.
Clean Code is not a soft-skill book.
Clean Code: A Handbook of Agile Software Craftsmanship, by Robert C. Martin.
Clean Code is a great book if anyone is interested in commenting guides.
Clean Code: A Handbook of Agile Software Craftsmanship by Robert Cecil Martin
Uncle Bob (one of the founders of Agile manifesto, author or
Clean Code and Clean Coder) commented this week (
http://twitter.com/unclebobmartin/status/19904664214):
Never allow a manager to convince you to break your disciplines in the interest of speed. It'll just make you go slower.The best documentation is the code itself. Check out the book Clean Code for great details.
Have you considered contributing to an open source project that you respect?
Picking a side project is a great way to learn and grow.
If you learn from books, I would recommend Test Driven Development by Kent Beck, Clean Code by Robert Martin, The Philosophy of Software Development
County Zero by William Gibson
Working my way through the "Sprawl trilogy" :)
Also, Clean Code: A Handbook of Agile Software Craftsmanship by Robert C. Martin.
I highly recommend (to everyone here for that matter) the book
Clean Code: A Handbook of Agile Software Craftsmanship by Robert C. Martin.
It deals specifically with the mistakes you've mentioned in your post, such as hardcoding and naming functions.
Great easy read.
Cheers
Read Clean Code by Robert Martin
It isn't easy, but so far I've had luck with my co-workers. If they were more dogmatic, I think I would see Clean Code more critical too. But as it stands, I still recommend the book to new colleagues, and our culture takes care that we don't follow each "law" to its letter.
Check out Clean Code by Robert C. Martin. May be helpful.
Building a Career in Software is a good one I read recently.
Did not finish Clean Code yet but enjoying it so far too.
Clean Code -- Robert C. Martin
I'm a big fan of Robert C. Martin's
Clean Code principles.
There should be some kind of ESLint preset that enforces these principles where possible?
I also own Code Complete. Its a good book, but I think Clean Code is a little shorter and easier to digest.
One of the things in the
Clean Code book really helps.
Methods and functions should be around 5 lines.
Doesn’t always work but is great to aim for.
Both books are good, and I don't believe Clean Code is praising the glory of agile dev, it talks about technical good practices ... practices that can be applied to any objected oriented language in general, doing agile or waterfall or whatever ... IMHO.
Yep, read these books and apply the ideas directly to your work as you go: Code Complete (which IMO is more detailed and explanatory than Clean Code) then Clean Architecture.
It's weird that you mention a book like Clean Code to a person worried about potential gaps in their CS education. I mean, they don't teach it at universities, right? Chances are, if he's self taught he knows Clean Code better than average graduate.
I own Code Complete, but I felt I got better value out of the
Clean Code book combined with the Pragmatic Programmer.
I did find some value in Code Complete, but it is a little too long for my tastes. The naming and abstract data structure sections were probably my favorite parts of that book.
> The goal is to develop the wisdom, that makes you a great engineer, not to "follow all of the rules"
This is why books like Clean Code can be harmful. It can be extremely dogmatic if blindly followed, which is very common unfortunately.
Read Clean Code (they are in video form) or Code Complete 2 and Refactoring books and LEARN what makes a design better than another. Talk with your colleagues about design choices in person and ask why they think one design is better than another. I truly think it's learnable.
Technopoly ought to be considered in that group of books held as 'mandatory reading', alongside 'Mythical Man Month', 'Clean Code', and 'The Soul of a New Machine'.
Clean Code is not a blind religion, Uncle Bob is trying to make a point with the concepts behind the book and teaching you to consider/question if you're falling into bad code traps.
This book was written to make developers think and consider their choices, not a script for good code.
Clean Code is still a great read in 2020, but I think you’re right about some of the specific advice about functions.
Something simple you can start with is naming. practice choosing better variable names, argument names, and function names.
Take a look at the Clean Code book. The chapters on functions and naming are some of the best.
I first encountered him with this book:
Designing object-oriented C++ applications using the Booch method
and really liked:
Agile Software Development: Principles, Patterns and Practices.
I didn't think Clean Code was worth it though.
Clean Code by Robert C. Martin. It's not a book to learn how to code but a book that gives good habits on how to write clean code which I think is very useful regardless of languages.
Books: Operating Systems/Database/Networking/Computer Security/Computer Architecture textbooks, Software Engineering textbooks (Clean Code, Design Patterns, Designing Data Intensive Applications, Domain Driven Design as a short list off the top of my head)
If I'm remembering correctly this article seems to mostly paraphrase what the various developers Robert C. Martin interviewed for this book ("Clean Code: A Handbook of Agile Software Craftsmanship") said...in mostly the same order.
How fast can you read?
- Clean Code
- Code Complete 2
- The Pragmatic Programmer
- Professional PHP
- Effective Java
- Domain Driven Design Distilled
I don't remember reading Clean Code, but reading Code Complete (in the '90s) was a real eye-opener for me. It's a very friendly book with practical advice that's still valid even after 2-3 decades...
I can highly recommend reading the "Meaningful Names" chapter in
Clean Code for practical and useful advice on this topic (some good notes here
http://www.itiseezee.com/?p=83)
For a general software developer, I have seen Code Complete (Steve McConnell) and Clean Code (Robert C. Martin) recommended a lot. I have copies of both on my desk at work.
The list is missing Clean Code, Clean Architecture, The Clean Coder, and Domain Driven Design. Also, while the books on the list look great a bunch of them are for very specific topics that don't have much to do with the majority of programming.
I've seen a of lot enigeers that don't understand fundamentals and it causes a lot of problems in real-world software. These are my goto recommendations:
Code Complete: A Practical Handbook of Software Construction, Second Edition
Clean Code: A Handbook of Agile Software Craftsmanship
I would focus on communication skills. Knowing what the end user wants is really important.
For technical skills, I recommend reading Clean Code, Test Driven Development, and The Philosophy of Software Design.
Disagree. There are zillions of worse books than Clean Code to forget first.
What are notable books nowadays? It seems all the books I can cite are from 2005-2010 (Clean Code, JCIP, even the Lean Startup or Tribal Leadership…) but did the market for legendary books vanish in favor of Youtube tutorials? I’m running out of materials I can give to my interns to gobble knowledge into them in bulk.
I never read Clean Code and know nothing about its author so I'm willing to trust you on the first part, but the second paragraph is really uncalled for IMO. The article is long and gives precise examples of its issues with the book. Assuming an ulterior motive is unwarranted.
Code Complete is a great book that thankfully my first boss required me to read when he hired me but I personally feel that Clean Code covers most of the same and is an easier read. Just my two cents thought.
Very helpful list! reminds me of the book Clean Code
A lot of the points in this article are also in other works on the topic such as Kent Beck's Test-Driven Development by Example, and Clean Code by Robert Martin.
Also, as others have mentioned, do play the numbers game. Apply to as many positions as you can.
Be polite and friendly (lots of rejections happen because of bad attitude).
Would recommend reading Clean Code. Might help you improve the quality of the programs you write during interviews.
Code Complete seemed to be a book with a lot of dense, redundant content. Reading what was written had me feeling like I was reading information that could have been written by myself. Clean Code on the other hand (along with Refactoring by Martin Fowler) changed the way I write code for the better.
Yeah, single responsibility principle is the key takeaway from that book.
Clean Code is a must for all programmers and I can recommend it as a prequel to CA. It's written by the same author after all.
I have a feeling the OP is looking for a book about software development in a broad sense.
I think Clean Code is a bit overrated. I got the book, and while some of the advice is sound, especially from OOP perspective design, a big part of the book is solving JavaEE specific issues, which don't translate well to other languages.
To have read Code Complete (now edition 2). I'd add
Clean Code to that list as well.
Looking back 24 years, I'd also add, to be more involved in the local hacking community and participate in hackathons.
Anybody can code, but to make a difference, you need to network ;)
I would say that, unless you're just starting your career, books like
Clean Code, The Pragmatic Programmer and the like are not real "revelations".
Software engineering has more to do with people than with software. Have you checked Peopleware? Also, perhaps The Phoenix Project could help as well.
- "
Clean Code: A Handbook of Agile Software Craftsmanship" by Robert C. Martin
- "Physics for Future Presidents" by Richard Muller
Not really a book but I found the "MIT Guide to Lock Picking" an interesting read.
Code Complete rocks. It's easily in the top 20 books for any developer. Maybe top 5
Having said that, remember the idea is to stick with a theme, so if you choose good coding, do "Clean Code" by Uncle Bob a few other books along the same lines.
I understand that the people that follow Clean Code religiously are annoying, but the author seems to be doing the same thing in reverse: because some advice is nuanced or doesn't apply all the time then we should stop recommending the book and forget it altogether.
I've recently read Clean Code by Robert Martin and now totally agree with the OP; everyone should go and read it, though it's full of annoying Java, it does apply equally to proper languages.
Under-substantiated?! The guy was one of the signers of the original Agile Manifesto, and think what you will about big-A "Agile", the manifesto itself was a revolution in our industry, It may not seem that way now, but only because of how thourgly the ideas of the manifesto have been integrated into our culture. Then he wrote his whole
Clean Code series which are generally considered necessary reading for any junior developer. Then after that he's basically been the senior dev at 8th light, which is both a highly successful consultancy and an excellent example of a company creating a structured mentorship program for new developers.
So yeah, feel free to disagree with Uncle Bob, but in no way is he "under-substantiated.
I would like to start with:
High Output Management Grove, Andrew S.
7 Habits Of Highly Effective People Covey, Stephen R
Clean Code: A Handbook of Agile Software Craftsmanship,(Robert C. Martin)
Clean Architecture: A Craftsman's Guide to Software Structure and Design (Robert C. Martin Series)
Building Evolutionary Architectures: Support Constant Change by Neal Ford, Rebecca Parsons, Patrick Kua
If you have read any of them and you would like to share your thoughts, I will be truly happy to listen!:)
Happy reading
Hammer the people who should be coming up with requirements, the BA or PO or whoever it is to take responsibility for proper requirements. From your end read things like the Clean Code book and Head first design patterns.
It's directly from the article, and
Clean Code was one of the first books I purchased.
Fixed the typo, thanks.
What do I recommend for a teen programmer? Unit testing.
Best resources and books? There are just so many good books. Last one I enjoyed was The Pragmatic Programmer. Next I'm going to try reading Clean Code.
Keep learning. Keep reading. Keep writing.
Reading the first ten chapters of Clean Code takes no more than 3 days yet so many programmers fail to do so. There is literary no other way to improve your coding skills and habits that fast.
His book
Clean Code would be a good start to what he has to say. The SOLID principles are important.
Then I'd move on to Domain Driven Design and probably Refactoring and Growing Object Oriented Software, Guided By Tests.
Those four will give a good start to what enterprise/OO people are expecting in design.
I've read most of the recommended books, but as far as what I think has delivered immediate real value, I'm going to go with:
1) Clean Code
2) The Phoenix Project
3) UNIX and Linux System Administration Handbook
I'm sure #2 will be something folks want to fight over shrug. If you want to sidestep years of headache it's a must-read though.
I am interested in reading books about software development and best practices like
Clean Code and The Pragmatic Programmer [0]. I have coded for about eight years, but I would like to do it better. I would like to know your opinion about [0], since Clean Code has been significantly criticized.
[0] https://pragprog.com/titles/tpp20/the-pragmatic-programmer-2...
As Uncle Bob describes in his book, you never even make abstractions until you have proven duplication. You make your abstractions based off of evidence, not hypothetically planned out.
Kent Beck in his book doesn't recommend top-down, or bottom-up, but rather from known-to-unknown. Start with what you know, and work toward what you don't know.
Edit: The books I refer to are Test Driven Development: By Example - Kent Beck, and Clean Code - Robert Martin
Aside from the spaghetti code that my predecessor wrote, I've been reading a book called "Clean Code: A Handbook of Agile Software Craftsmanship" by Robert C. Martin. The code in the book isn't always interesting for content, but rather for style and craft. He does a great job explaining industry best practices, along with How and Why they are used.
The question is should the writer go through the effort of placing the parameter name, or should the reader go through the effort of looking up the function prototype? Since according to
Clean Code (
https://www.goodreads.com/quotes/835238-indeed-the-ratio-of-...) code is more often read than written, it should makes sense for the writer to do it.
InclinedPlane mentioned "Working Effectively with Legacy Code," and I'd just like to add that's one of the greatest software engineering books out there.
Feathers (the author) methodologically chose to copy / inspire some of his examples from code he's worked with as a mentor / developer (some of it from his time @ Thought Works w/ Beck, et al.)
The book is similar to Fowler's Refactoring in that it provides some core thought processes / ideology and then a long list of heuristics and techniques for revising/updating legacy code. (I find his definition of "legacy code" as any software without automated testing to be challenging and insightful, especially since it indicts most code written ever. ;)
If you get the chance, you could also consider reading "Clean Code", it doesn't have /as much/ "real world" source but is still excellent.
This is all motherhood and apple pie and such, but I guess it deserves repeating from time to time. He's got that
Clean Code book out, which is a pretty good read.
What I want to know is how in the heck do you get to call yourself "Uncle Bob"? What? Is there like an agile family, with uncles and nephews and stuff? If so, I want to be Cousin Dan
Another excellent resource is "A Philosophy of Software Design" [0], from John Ousterhout (known for Tcl/Tk, Raft, RAMCloud, Log-Structured File System). Like Niklaus Wirth, he is striving for designs that fight complexities and yield simple and powerful abstractions. This book is so much better than overrated books like "Code Complete" and "
Clean Code" for a fraction of the page count.
[0] https://www.amazon.com/Philosophy-Software-Design-John-Ouste...
You do realise even the founder of TDD doesn't back it anymore and code coverage is a very poor metric, your words sound like a senior developer from 2010. If he's a bad developer the best he can do is read up on SOLID principles and read a book like Clean Code with good examples of how to write code.
To be entirely honest, most of his books are pretty awful, as they are mostly preaching something for the sake of preaching and selling the books. I bought his last one (Clean Architecture) as I wanted to improve myself as an architect, just to realize its riddled with fluff and rarely anything in there is actionable advice. For some reason the reviews from his followers are mostly glowing.
I also found myself agreeing with everything written in this blog post. For the record I have read his famous Clean Code, Clean Coder and Clean Architecture and I don't find them all that meaningful.
The most important one is this:
http://agilemanifesto.org/Yes, it is only 3 paragraphs and a title, but if you want it in book form you can print it out and put it between some covers. The important thing is to read those 3 paragraphs carefully and to think about them. Avoid getting caught up on the bandwagon of some management methodology that claims to be Agile, because it probably isn't.
And read Clean Code by Robert Martin, one of the writers of the Agile Manifesto. One of the things encouraged by Agile is TDD, that is to say, a cycle of coding that starts by writing a failing test, then writing code to pass the test and then refactoring code to be better according to principles like DRY and YAGNI.
If you work in this Red-Green-Refactor cycle, then you will have a tough time when faced with a tangle of spaghetti code written in Java or C++. That's when books like Working Effectively with Legacy Code by Michael Feathers come in handy.
In general, steer clear of books about Agile, and focus on books that teach something real, but happen to fit into the Agile Manifesto philosophy. Talk to some developers that you know are truly Agile developers, not practitioners of a methodology, and ask them for book recommendations.
Honestly
Clean Code probably isn't worth recommending anymore. We've taken the good bits and absorbed it into best practice. I think it has been usurped by books like "Software Engineering at Google" and "Building Secure and Reliable Systems".
I don't believe in being prescriptive to anyone about how they write their code, because I think people have different preferences and forcing someone to write small functions when they tend to write large functions well is a unique form of torture. Just leave people alone and let them do their job!
I don't think it is the perfect solution, but a lot of people assert "we can't do better, no point in trying, just write whatever you feel like" and I think that is a degenerate attitude. We CAN find better ways to construct and organize our code, and I don't think we should stop trying because people don't want to update their pull requests.
I'd recommend the following:
Clean Code: A Handbook of Agile Software Craftsmanship [0] is a great book on writing and reading code.
Similarly, Clean Architecture: A Craftsman's Guide to Software Structure and Design [1] is, no surprise, a book on organizing and architecting software.
Designing Data-Intensive Applications [2] may be overkill for your situation, but it's a good read to get an idea about how large scale applications function.
The Architecture of Open Source Applications [3] is a fantastic free resource that walks through how many applications are built. As another comment mentioned, reading code and understanding how other programs are built are great ways to build your "how to do things" repertoire.
Finally, I'd also recommend taking some classes. I started as a self-taught developer, but I've since taken classes both in-person and online that have been a tremendous help. There are many available for free online, and if in-person classes work better for you (motivation, support, resources, etc), definitely go that route. They're a fantastic way to grow.
[0]: https://www.amazon.com/Clean-Code-Handbook-Software-Craftsma...
[1]: https://www.amazon.com/Clean-Architecture-Craftsmans-Softwar...
[2]: https://www.amazon.com/Designing-Data-Intensive-Applications...
[3]: http://aosabook.org/en/index.html
Everyone talks about clean code, but where are the real world examples? Javascript, Python, something useful and which inspires that the ideal of clean code is actually possible.
I'm considering the perspective that think clean code is this ideal that can be misused by reviewers to blackball otherwise good code for arbitrary personal reasons.
I know the book Clean Code and I like the ideas in it. I just haven't seen any production examples and I'm considering the idea that talking about clean code is a hand waving way to criticize others contributions without substance.
His changes did increase the cohesion in the codebase BUT they also increased the coupling. Ideally you minimize coupling and maximize cohesion.
The book Clean Code specifically addresses this area and his final conclusion is compatible with the concepts of clean code.
I think devs should read Clean Code multiple times during their professional life.
Read the clean code book by Rob Martin and the head first design patterns book. Both are musts for software engineers and Amazon top sellers for developers. Other than that be like a sponge and learn transferable skills in one or two mainstream languages, you can't go wrong with Java, c#, sql and angular.
Care to elaborate what bits of
Clean Code are damaging?
I've read it and I thought it has some good ideas. It's the #3 most discussed book on StackOverflow. However, I've been downvoted on HN for recommending something the book talks about (comments are usually misused)
Maybe I'm missing something more experienced developers know.
My top priority books:
Software Requirements - Karl Wiegers
Programming TypeScript - Boris Cherny
Associate Cloud Engineer Study - Dan Sullivan
Design Patterns - Gang of Four
Refactoring - Kent Beck, Martin Fowler
Programming Pearls - Jon Bentley
Patterns of Enterprise Application Architecture - Martin Fowler
The Pragmatic Programmer - David Thomas, Andrew Hunt
CSS: The Definitive Guide - Eric A. Meyer, Estelle Weyl
Working Effectively with Legacy Code - Michael Feathers
Head First Design Patterns - Eric Freeman, Bert Bates
Code Complete - Steve McConnell
Peopleware - Tim Lister, Tom DeMarco
Clean Code - Robert C. Martin
The Clean Coder - Robert C. Martin
Clean Architecture - Robert C. Martin
Don't Make Me Think - Steve Krug
Functional Design Patterns for Express.js - Jonathan Lee Martin
The Surrender Experiment - Michael A. Singer
The best books I've ever read:
Principles - Ray Dalio
The Power of Now - Eckhart Tolle
The Effective Executive - Peter F. Drucker
Think and Grow Rich - Napoleon Hill
Extreme Ownership - Jocko Willink, Leif Babin
Influence - Robert B. Cialdini
The Startup Way - Eric Ries
The Lean Startup - Eric Ries
12 Rules for Life - Jordan B. Peterson
Measure What Matters - John Doerr, Larry Page
The Fish That Ate the Whale - Rich Cohen
The E-Myth Revisited - Michael E. Gerber
The Score Takes Care of Itself - Bill Walsh, Steve Jamison, Craig Walsh
Management - Peter F. Drucker
Thinking in Systems - Donella H. Meadows
Blue Ocean Strategy - W. Chan Kim, Renee Mauborgne
Clean Code by Robert Martin. You'll see it mentioned frequently on HN and online in general. Changed the way I wrote code almost immediately. I kind of wish it had been a part of my university curriculum. I'm sure we HNers can pick on the book for this and for that (can't any book?) but overall I think it's excellent.
For other books, this page is also a good start: https://hackernewsbooks.com/top-books-on-hacker-news
In no particular order the best ones I've read this year(so far) are:
Children of the Nameless by Brandon Sanderson - Probably one of the few very good magic the gathering books.
Augustus: The Life of Rome's First Emperor by Anthony Everitt - excellent overview of the emperor
King Rat by James Clavell - fictional depiction of being a prisoner in a Japanese camp during WW2.
1493: Uncovering the New World Columbus Created by Charles C. Mann - talks about the natives in the Americas after first contact. Follow up to 1491.
Clean Code: A Handbook of Agile Software Craftsmanship by Robert C. Martin - Good book for people looking to write clearer, more understandable code
The Elric Saga Part 1 by Michael Moorcock - Interesting protagonist.
Currently enjoying and will finish by end of year:
The Starless Sea by Erin Morgenstern - It's about stories so far. If you liked the Night Circus, then you will like this. Great atmosphere.
May I ask what book would you rather recommend?
While I do think that Bob goes overboard with his suggestions in Clean Code, I found it as a necessary counterbalance to encourage readable code in my team, where the methods tends to be gigantic blobs. I'm sure there are better books, but it was a good one.
For instance, one suggestion I did like from Clean Code is to separate exception handling from business logic. I don't always practice it, but it really helped in making my work-related code more readable.
Accelerate: Building and Scaling High Performing Technology (great!)
Dare to Lead (interesting and Powerful)
Rising Strong (Sensible)
What the most successful people do before breakfast (helpful in thinking about opportunity costs)
Why we sleep (interesting read)
Exponential organisations (Re-read after 2 years, worth it)
Prisoners of Geography (very interesting view of geopolitics, Putin, et al)
Continuous Delivery (great!)
Clean Code (must read for any serious programmer)
Built to last (picked it back after 1-2 years, cool book)
Site Reliability Engineering (didn't quite finish, but good book)
Building Microservices (fantastic book which puts everything I've done in the past year into so much more perspective)
Robert Martin and his aura always struck me as odd. In part because of how revered he always was at organizations I worked. Senior developers would use his work to end arguments, and many code reviews discussions would be judged by how closely they adhere to Clean Code.
Of course reading Clean Code left me more confused than enlightened due precisely to what he presents as good examples of Code. The author of the article really does hit the nail on the head about Martin's code style - it's borderline unreadable a lot of times.
Who the f. even is Robert Martin?! What has he built? As far as I am able to see he is famous and revered because he is famous and revered.
Comments that don't document public interfaces are a code smell and should be avoided in all but the most exceptional circumstances. Reading Robert C. Martin's Clean Code really opened my eyes to this issue. Your emphasis on this in the code people write might exclude some people who avoid comments deliberately.
In no particular order the best ones I've read this year(so far) are:
Children of the Nameless by Brandon Sanderson
Augustus: The Life of Rome's First Emperor by Anthony Everitt
King Rat by James Clavell
1493: Uncovering the New World Columbus Created by Charles C. Mann
Clean Code: A Handbook of Agile Software Craftsmanship by Robert C. Martin
The Elric Saga Part 1 by Michael Moorcock
Congrats on your will and enthusiasm, I believe this is already a great first step!
Besides Martin Fowler which was already recommended, I would also recommend the books by Robert C. Martin (Uncle Bob), and his "Clean" series - there are books "Clean Code", "Clean Architecture" - all of them are really good and useful and will give you a solid foundation to build on.
Other than that, the best thing you can do is to get practice & ideally surround yourself with more experienced developers. Either get an internship in a company building something more complex, or participate in e.g. Google Summer of Code.
Doing fun side projects is also a great way - you learn a lot and also have something to show & write about - win-win!
I think there is some value in certifications as a way of teaching unusual corner cases you might not otherwise come across.
I only have one cert - the Sun Certified Java Programmer, from back in the day when Sun still existed - and i can say it encouraged me to dive deeper into the quirks of the language. For sure, reading Effective Java gets you more bang for the buck in becoming a great Java developer, and stuff like Clean Code probably helps more with learning how to build maintainable apps, but i still feel like the SCJP was worth my time to do.
The thing i found about doing the SCJP is that it increased my curiosity around programming languages in general. Those contrived "gotcha" questions on visibility, inheritance etc made me think more deeply about how to design code in a readable and safe way - not just in Java but in other languages too.
Agree with all the CS Basics book (would add the Code: The Hidden Language of Computer Hardware and Software, great book and if he has time, I'd go for it). I'd also consider giving him a couple of books, like: A)
Clean Code by Bob Martin, B) Soft Skills by Jon Sonmez. Books that doesn't require a computer, yet teach the reader how a good developer should think while writing code and working in a team. It's also less likely he gets stuck while reading this kind of literature.
Would help if you shared the end goal. Get hired anywhere? Get hired by Top 4 Tech Company or Hot Startup of the Year? Start a business? Don't get bored? How long is he going to be incarcerated?
I would greatly appreciate if you shared your experience.
I'm a junior dev with ~2 years experience. Currently I'm primarily doing back-end web work on a massive spaghetti codebase written in Node, Python, and PHP.
My current reading list:
* Code Complete: A Practical Handbook of Software Construction - Steve McConnell
* Agile Software Development - Robert C. Martin
Upcoming reading list:
* Node.js Design Patterns - Mario Casciaro
* The Pragmatic Programmer: From Journeyman to Master - Andrew Hunt
* Clean Code - Robert C. Martin
* Refactoring: Improving the Design of Existing Code - Martin Fowler
And maybe Working Effectively with Legacy Code by Michael Feathers.
If anyone has any comments or other suggested readings I'd love to hear them!
I think the OP is spot-on on his takeaways from
Clean Code. I work with a number of people who do not have a CS or Software Engineering background but are assigned to the team as "programmers". They can hack together something that will work, but often end up with a convoluted design and an almost guaranteed maintenance nightmare.
Robert ("Uncle Bob") Martin's book has been really useful for us. We have been going through the book section by section and comparing the ideas in "Clean Code" to our implementations. It has been a most effective way of getting the team up to speed.
I would recommend anyone who is getting started on their first software engineering job to go through the book. It is excellent study material for an inexperienced team.
there is this quote from
Clean Code by uncle Bob that I simply love.
'Avoid mental mapping: In general programmers are pretty smart people. Smart people sometimes like to show off their smarts by demonstrating their mental juggling abilities. After all, if you can reliably remember that r is the lower-cased version of the url with the host and scheme removed, then you must clearly be very smart.'
Interesting article. I definitely try to avoid comments and let the code do the talking, I hope more devs would. My eyes ALWAYS skim over comments, unless I can't make sense of some agency dev's code, then I have to look at the comments if they exist.
Although I detest comments, making them stand out more and consequently wanting (hopefully) to write better code, is a plus. There will be some cases for comments, and it should be few and far between, and only super necessary (read Clean Code for contextual examples).
I've been mentoring junior engineers for fifteen years and I've found a lot of techniques that work but there are two ingredients that I think have to be present:
1) You're motivated to help
2) The junior engineer is motivated to improve
I don't think it matters what techniques you use if these two things are in place. If they're not in place then it is very likely not going to pay off regardless of how you approach the mechanics.
Code reviews are critical.
Pair programming can be a valuable technique.
Going over concepts and best practices can help.
Creating a plan for the junior engineer to study the craft. Books like Clean Code can be great at starting discussions.
Good luck!
Indeed, I think Robert Martin's "Clean Code" would agree that if you don't need to vary the "6 hours" part at run-time, then "findeventsfromthelast6hours" is actually better than passing in an "hours" argument ("Clean Code" advocates minimizing function arguments). Refactoring the name in the face of a one-time change in behavior (e.g. "4hours") should be trivial with any modern IDE.
Code quality means a lot in my opinion. A nicely structured and organized code not only shows its programmers' expert skills but makes it easier (and faster!) to modify or extend the present functionalities. Also if you care about code quality it really helps you to develop your skills.
As others stated it is needed to start a project in a way that you care about the quality. Even when there have not been a single line written. Also being agile also means that you refactor and redesign from time to time when it is needed.
I always check my code after implementing a functionality. If it is needed, I refactor my code. Also there are numerous tools to check code quality (e.g. Sonar). A very good approach is to have code reviews as well if you can.
There is a very nice book in this topic which the others have not mentioned, but if you are interested I advise to read it: Clean Code by Robert C. Martin.
I'm reading
Clean Code (again). I dont see that code as being particularly bad. But it definitely wouldnt follow the axioms in that highly regarded book. I realize it isnt java but can someone familiar with the text comment on the number of parameters in that function and the naming of some of those variables?
Relevant quote:
"The ideal number of arguments for a function is zero (niladic). Next comes one (monadic), followed closely by two (dyadic). Three arguments (triadic) should be avoided where possible. More than three (polyadic) requires very special justification—and then shouldn’t be used anyway."
It is very common. But it depends upon who leads the team and how many resources they have.
When I hire a new developer, I always have them read TDD and Clean Code. Even if they don’t get it right away, I aim to get them to pause and think about it.
Some quick software that was written in haste could be running over a decade. And they might be stuck maintaining it
Agreed with all the previous comments.
URL Design is key. I often refer to the naming chapter of Uncle Bob's Clean Code book for this. This also helps with consistency and predictability, which in turn, makes writing docs easier.
I've got an API Design Readlist, which I've added this thread to. http://readlists.com/6c5c6009/
TL;DR - It depends ;)
The examples you provided (with some context gleaned from your other comments) look like they're probably too long and tack on unnecessary domain specific detail (e.g. jsonStates).
Both variables in your example would likely be better off describing the use of the variable rather than the contents. E.g. use ageInYears rather than yearsAliveInt. Taking it to your example, perhaps something along the lines of convertedDocument would do, this is significantly shorter than your example, but perhaps conveys enough info for your ongoing usage.
This is covered to in Clean Code [1]. "The name of a variable, function, or class, should answer all the big questions. It should tell you why it exists, what it does, and how it is used." The notes on the naming chapter at [2] are quite good as well (as noted elsewhere on this thread by @runesoerensen)
I like to follow the principle in naming variables that if I could read the code to a non-technical user verbatim and have them understand the code, it is "good code". I.e. does reading the code out loud as a sentence make sense, or do the verbs and nouns I've chosen act as a barrier to understanding.
EDIT:
Ward Cunningham said that last part better:
“You know you are working on clean code when each routine you read turns out to be pretty much what you expected. You can call it beautiful code when the code also makes it look like the language was made for the problem.”
[1] Martin, Robert C. (2008-08-01). Clean Code: A Handbook of Agile Software Craftsmanship (p. 18). Pearson Education. Kindle Edition. https://www.amazon.com/Clean-Code-Handbook-Software-Craftsma...
[2] http://www.itiseezee.com/?p=83
Pragmatic Programmer is still a good book, not as revealing as before but still has lots of good advice.
Code Complete is a problematic book. It has some good ideas but also has some very bad ones (cone of uncertainty, 10 times productivity in good programmers, etc).
Design Patterns is mostly obsolete. Functional programming techniques made a lot of Object Oriented techniques irrelevant (e.g.: observer pattern vs callbacks with lambdas).
Art of Computer Programming is the book everyone mentions but no one reads. A classic that people actually read is Structure and Interpretation of Computer Programs.
My recommendations: "Code" by Charles Petzold,"Don't make me think" by Steve Krug, Working Effectivelly with Legacy Code, by Robert Feathers, Clean Code by uncle Bob,..
It's interesting to note that this presentation strongly contradicts the advice of "The Pragmatic Programmer" and "
Clean Code", which are highly respected by many. Does this mean that those books are wrong, or does it mean that Facebook will eventually come to regret their philosophy? Or maybe writing this kind of code is somehow fundamentally different, so the usual wisdom and rules of thumb don't apply.
I really don't know the answer, but find it fascinating and can't wait to see what Facebook is doing in 10 years time.
Now if only he would learn that most of the books left on his bookshelf are likewise window-dressing in front of fundamentals:
* The Pragmatic Programmer
* Clean Code
* The Clean Coder
* Domain-Driven Design
* Growing Object-Oriented Software, Guided by Tests
All of these books take the simple maxim:
"Be organized, and stay organized"
and spend thousands of pages expanding on that.
Not the OP, but my advice would be:
Read the "classics" - Code Complete, Pragmatic Programmer, Clean Code etc. Google "best books about programming" and you'll find plenty.
When you're reading think about the why. You're job is dealing in complexity and there is no one true way. Understand as many of the different ways as possible.
If you think an idea is weak, try and figure out a question that exposes the weakness (how does this handle a date before 1970?). Expect that sometimes this question will reveal the idea isn't as weak as you initially expected.
Remember you only need to solve the problem that's in front of you. If that problem doesn't seem easy try to break it up into smaller problems.
Complicated solutions are often bad solutions.
Complicated solutions can be good solutions.
Write your code for people to understand.
Advice on good writing is often very applicable to code... See Orwell(1), particularly "Break any of these rules sooner than say anything outright barbarous"
1.https://www.writingclasses.com/toolbox/tips-masters/george-o...
2340 (the mandatory group project course) also covered a lot of this stuff, though not in as much detail.
The suggested reading for that course is a book that blew my mind when I first saw it as an undergrad: Clean Code by Robert Cecil Martin. I believe the examples are all Java, but the lessons are applicable to any language. Stuff like naming your variables more carefully than you name your children.
https://www.amazon.com/Clean-Code-Handbook-Software-Craftsma...
Other people have already said most of what I wanted to say – that self-explanatory code, and sometimes tests, is almost always better than comments. I just want to point out a good reference on this topic: the book
Clean Code: A Handbook of Agile Software Craftsmanship [1], specifically Chapter 4, “Comments”. That chapter gives examples showing which comments should be turned into code and which are acceptable to leave as comments, and it explains the reasoning behind the choices. (And the rest of the book teaches you
how to make your code self-explanatory and easy-to-read.)
[1] http://www.amazon.com/Clean-Code-Handbook-Software-Craftsman...
The Pragmatic Programmer, Refactoring (I'm rereading it after many years with the 2018 edition, opinion not totally formed on this one), Working Effectively With Legacy Code, A Philosophy of Software Design. It's been a long time since I've read Clean Code, I don't quite get the hate from the other thread here today so I'm rereading it now. I figure it'll take me a couple days and worst case I'll agree with the criticism and stop recommending it.
I, for one, recommend "
Clean Code". It did not "change my life" because I was already on the path the book describes. Nonetheless it was a good validation, it certainly coalesced in a good form many topics that were simply fluctuating in my mind, and is a good reference to have around for refreshing once in a while.
To put this in context: I keep it next to "Agile Software Development" (by the same Uncle Bob), "Working Effectively with Legacy Code" (by M. Feathers), and "Refactoring" (by M. Fowler).
HTH (no, I have no direct or indirect benefit from 'advertising' these books and their authors)
Well said, I was cringing when I was reading the bad advice and you addressed the points very well.
It is so frustrating to hear when someone thinks commenting more and adding humour is somehow cleaning up the code. But to then hear that they are teaching this to juniors just hurts so much.
Simpler advice to juniors would be to read Clean Code by Robert C Martin, apply some of those techniques and then politely ignore “more experienced” developers who think writing humourous essays as code comments is a good thing.
I’ve even heard phrases banded around like “the more comments the better” - I mean seriously WTF.
I like the analogy of...
When in an unfamiliar city, having no map at all is much better than a map that you have no idea whether you can trust or not. Code comments are absolutely that untrustworthy map, doesn’t matter how many code reviews or convoluted PR process takes place, you still need to read the code to know the truth so more effort making the code communicate is the key to maintainable code. Simple things like good variable names and grouping behaviour into functions at the same level of abstraction can completely negate the need for comments.
Comments have their place, but should be the exception not the norm.
> I also noticed, that a lot people talking about the principles of "Clean Code" (either PRO or CON) did NOT even read the book (entirely) nor hat other sources of wisdom ;)
In your opinion, why do you feel any of those points you made are relevant or have any substance? I mean, the importance of Clean Code is to improve your output by following a few guidelines, not be pedantic and use the book as bible to bash others in bike shedding discussions.
I think it's great that Keli is designed with IDE support in mind. However I believe that this is only half of the reason why FP still doesn't really break through in the corporate world.
The other reason is that many FP users are too enthusiastic about creating abstractions.
This is of course something that FP is exceptionally well suited for. An api that was written to simply process a list of Orders into a Report might be abstracted into a fold on some monad, which at first seems a great idea.
But if you're not careful, readability suffers a lot. It's much easier to get to know an application when its code deals with business objects that you already understand well, than to read hundreds of lines of code that deal only with abstractions.
Maybe there should be a new edition of Clean Code written specifically for FP, to address this anti pattern.
By the way this problem is not unique for FP, OOP suffered the same problem in the past. But the OOP community learned from its mistakes and now most developers know to 'prefer composition over inheritance', for instance.
I might as well get all of the big names out of the way.
* Design Patterns: Elements of Reusable Object-Oriented Software
* Refactoring: Improving the Design of Existing Code
* Clean Code: A Handbook of Agile Software Craftsmanship
* Code Complete: A Practical Handbook of Software Construction
And some others:
* Working Effectively with Legacy Code
* Domain-Driven Design: Tackling Complexity in the Heart of Software
I think one should always be careful not to throw out the baby with the bathwater[0].
Do I force myself to follow every single crazy rule in Clean Code? Heck no. Some of them I don't agree with. But do I find myself to be a better coder because of what I learned from Bob Martin? Heck yes. Most of the points he makes are insightful and I apply them daily in my job.
Being a professional means learning from many sources and knowing that there's something to learn from each of them- and some things to ignore from each of them. It means trying the things the book recommends, and judging the results yourself.
So I'm going to keep recommending Clean Code to new developers, in the hopes that they can learn the good bits, and learn to ignore the bad bits. Because so far, I haven't found a book with more good bits (from my perspective) and fewer bad bits (from my perspective).
[0]https://en.wikipedia.org/wiki/Don%27t_throw_the_baby_out_wit...
I’d say “Stop recommending
Clean Code to noobs! It’s dangerous”
Because Clean Code is really a good book once you have enough experience to understand when each idea works and when does not. And why.
And noobs tend to over-engineer, so any book like CC or design patterns give them additional excuse and reason to over engineer and make a mess.
But the problem isn't so much because the book has a mix of good and bad recommendations. We as an evolutionary race have been pretty good at selectively filtering out bad recommendations over the long term.
The problem is that Uncle Bob has a delusional cult following (that he deliberately cultivated), which takes everything he says at face value, and are willing to drown out any dissenting voices with a non-stop barrage of bullshit platitudes.
There are plenty of ideas in Clean Code that are great, and there are plenty that are terrible...but the religiosity of adherence to it prevents of from separating the two.
>
I've read "Code Complete", "Clean Code", "Extreme Programming Explained" and thought that "real" developers solve interesting problems and write maintainable and high-quality code covered by unit tests. Remember that the people who wrote those books cut their teeth in the pre-web days. It was a much different world back then; there was a huge incentive to get things right the first time because patches were difficult to get to users.
Jobs like the kind you describe exist but are uncommon; usually they can be found in businesses that build tech products and platforms (software or hardware) or in the FAANG companies. Given your background, I'd suggest looking for a job at one of the games middleware companies if you haven't soured on the idea of being a developer entirely.
Any book written by Charles Petzold is an enjoyable read, though particularly the non-MS specific titles Code and The Annotated Turing.
Java Concurrency in Practice (2006) is older but relevant and clearly describes concurrency on the JVM. A must read for any Java, Scala, Clojure, etc. software engineer; well-written, enjoyable, concise.
Practical Object Oriented Design in Ruby by Sandi Metz is a fun read packed with good principles for working in Ruby that are applicable in general to object oriented programming.
Smalltalk Best Practice Patterns by Kent Beck is worth a read because the general principles are applicable to any OOP language.
Clean Code by Robert Martin is excellent but a time commitment. (If you had to pick between SICP and Clean Code because time is at a premium I'd err on the side of Clean Code for practicality. Writing maintainable code is paramount.)
The Joy of Clojure (Fogus/Houser) is excellent and mentally digestable even if you have no Lisp or Clojure background.
The short answer is: don't design for future use-cases.
Period.
Instead, only build what you need to solve the problems you have in-hand, but do so in such a way that your software and your systems are as easy to change as possible in the future.
Because you very, very rarely know what your future use-cases really are. Markets change over time, and your understanding of the market will also shift, both because some of your assumptions were wrong, and because you can never really have a total understanding of such a complex phenomenon.
Your business needs will change as well; your top priority from 2019 is likely very different than it is today.
That is why you build to embrace change, rather than barricade against it.
As to how, I'd start with Sandi Metz's 99 Bottles of OOP: https://www.sandimetz.com/99bottles
Learning to write readable code is also pretty important; Clean Code is a good starting point (https://amzn.to/3168z3A), but I'd be keen to know of any shorter books that cover the same materials.
Growing Object-Oriented Software Guided By Tests (GOOSGT) is a good read as well: https://amzn.to/3du1sEL
Look up The Pragmatic Programmer and
Clean Code - they're decent books and I'm sure other people on HN have even better recommendations.
Also, you don't necessarily need to cover something completely in order to get started. And these will be useful mostly if your work is in some way part of a software product instead of being some "offline" analysis, model build or forecast. Just learning to use version control, to collaborate with other developers and to run tests goes a long way.
That depends a lot on your current level and field. I myself am a junior frontend developer. I started from scratch through freeCodeCamp.org and I passionately recommend it to anyone to starting to learn to code.
If you passed that stage, I recommend the book The Pragmatic Programmer as a very good book on how to become a good software developer. The book Clean Code is a good starting point too.
Other than it depends on your circumstances. A good heuristic (particularly in frontend world) is to study the language, not frameworks.
That's sounds like example of someone with math skills applying them to make an awesome bit of code.
But I've also heard about math PhDs write the sloppiest code code imaginable: functions 1000+ lines long, copying and pasting functions to add a parameter... (in production code for a software company, not a research project).
So like you said, math helps but I'd like to extend that thought and say that you can make bigger gains elsewhere. For example, if you're a sloppy coder and don't know math, go out and get a book like "Code Complete," "The Pragmatic Programmer" or "Clean Code" first.
> [I use] additional variables for clarity, because the names can show what you're thinking as you do the computations involved in a complex expression
For me this was one of the greatest lessons of Clean Code by Bob Martin, in my opinion a wonderful book which completely changed and dramatically improved the way I write code. By improvement I mean simply the ease with which I can understand and modify my own code months after writing it/ seeing it last.
There's a slight contradiction here with another great lesson of that book though which is short code (by lines) > longer code simply because it's easier to consume in a single glance. There's certainly a delicate balance at play here.
It's a great thing to break down a complex process into steps, naming those steps as you go, and storing things in variables achieves that. However sometimes a better tool, and again another frequent suggestion in Clean Code (really, all credit to Bob Martin for all these ideas) is to instead break the steps into clearly-named functions, if this is possible. Chaining or nesting a series of function calls, depending on the language, can be more readable still than the variables approach and at the same time more concise.
Another great tool for the belt and one of the reasons I have come to always prefer programming in a functional style vs a more stateful, OO style, where I can (even within pretty OO languages such as Java - though the lambdas in 8 have greatly improved the ease with which this can be done).
I never read
Clean Code because of a kind of silly reason. I've worked with a couple of devs who read it and then decided the optimal number of lines of code per function was three. I always felt like I needed 6 monitors to be able to understand anything that was happening.
But if you recommend and say it's similar to Code Complete I'll give it a shot. What I liked most about Code Complete is he always talks about trade offs with a clear goal in mind. For instance if function sizes are too small hidden pre-conditions or side effects can cause a bug. But if functions are too large they are hard to follow and it's difficult to isolate side effects.
“Indeed, the ratio of time spent reading versus writing is well over 10 to 1. We are constantly reading old code as part of the effort to write new code. ...[Therefore,] making it easy to read makes it easier to write.”
― Robert C. Martin, Clean Code: A Handbook of Agile Software Craftsmanship
https://www.goodreads.com/quotes/835238-indeed-the-ratio-of-...
Aren’t the first 3 or 4 chapters basically what you can find in Google’s own cloud toturials?
Why does the domain-driven-design chapter come after you’ve tied the reader into GCP? I can’t think of a single enterprise business domain where that would make sense from a European GDPR driven perspective.
Why do you think you can cover that many topics in a single book? I mean, part of the reason Clean Code is well liked is because it covers one topic in depth, rather than covering a bunch of different topics without ever giving the reader anything of value on any of them.
Have you considered going the TDD GOAT book route of earning sales?
I’m really sorry that I’m so negative, but your “contents” read like every terrible tech-book I’ve ever opened. Good luck though.
You have quite overlap between some stuff. I would recommend "
Clean Code", but then skip the rest from the same author, at least for a while. While "Code Complete" is good, it's loooong and also a lot of the same stuff.
For patterns, "Head First" is a bit childish maybe, but the content is fine for someone learning to recognize patterns. "Patterns of Enterprise..." is also good, but more dry. I'd stick with one of those two. And then skip the one by GoF, unless you want to read the "original" for some reason.
"The Pragmatic Programmer" is probably the book that has shaped my work the most.
The main problem I've found (as an
modern JS developer) is that in many situations "mainstream" (AKA C/C++) CS topics are not so relevant to JS. Javascript is Async by default, function-based instead of OO (until recently), dynamic typed and was made to mess with the DOM.
So I feel like some of the concepts taught in the most recommended books such as Clean Code are only tangentially relevant and some times just plain irrelevant. On the other hand, massive books/material written for pure JS are really low quality compared to these classics (except some blog posts, but with these it's difficult to get a round education).
So the most difficult part for me was to find out which concepts were relevant for JS in high quality books and which were not, something that is not easy when you don't know these concepts. Then learn the things not mentioned that are important for a modern JS developer such as NPM, exporting modules, minimization+gzip+tree shaking, etc.
The classic
Clean Code by Robert C. Martin <- probably won't learn much new, but worth it, just to let the concepts reenter your consciousness.
The Secret War Against the Jews by John Loftus <- Changed the way I think about inner workings of the government. But at the same time, many claims are hard to verify.
The life changing magic of cleaning up by Marie Kondo <- not life changing but decent and a quick, 2-3 day read.
Nassim Taleb books, pretty sure everyone on here read it or plans to so, don't need my description.
Halfway through The Undoing Project by Michael Lewis at the moment, it's pretty good, a joint biography of Kahneman and Tversky (of the "Thinking, Fast and Slow", which I guess is another HN classic).
Here are my three:
"Unwritten Laws of Engineering" https://www.amazon.com/dp/0791801624
Originally meant for mechanical engineers, it provides specific and general non-technical career advice. It focuses on what we call “soft” skills today. This field puts so much weight into technical prowess that we often think of these “soft” skills as somehow beneath the “hard” skills. Nothing could be further from the truth. If you don’t spend time on learning how to navigate your career, you’ll be as well off as a dragster on the backroads: you’ll get nowhere fast. I only wish I could have read this book sooner; it would’ve saved me a lot of trouble early on.
"Becoming a Technical Leader" https://www.amazon.com/dp/0932633021
Don’t let the title fool you: this is not just for people planning on becoming a “Tech Lead.” It’s for anyone in the tech field, period. If you pickup this book you must work through the exercises to get the full effect. It will be worth it. It’ll be like having your own therapist, life coach, and mentor, except that it’s just you and a notebook answering very important questions.
"The Pragmatic Programmer" https://www.amazon.com/dp/020161622X
I consider this book 10x better than Clean Code and Code Complete combined! (Though that may just be because I read PragProg first?) As the name suggests, this book provides more tactics advice but also gives great career advice too. The most famous is to “learn a new language each year.” This kind of advice seems a bit much, but over my career I’ve had to write in over a dozen different languages, even though 90% of the code I’ve written has been in just one language, the ability to pickup new languages quickly and easily is a solid skill to have. And that’s just one particular tip from this book.
(These are excerpts from my suggested reads blog post: https://valbaca.com/posts/my-suggested-reads-3cie)
For me, there have been more than one. I'll list them in the order I read them. I have them all in an eBook form to read in my Kindle App on my Nexus 7.
1)
Clean Code2) Pragmatic Programmer
3) Patterns for Enterprise Application Architecture
There's some overlap in contents, but I feel they complement each other very well.
> these things are literally what the
Clean Code book advocates for
I'm not sure I understand what you're saying, I might be missing your point. The Clean Code book advocates that the ideal function is a single digit number of lines, double digits at the absolute most.
In my mind, the entire process of writing functions that short involves abstracting almost everything your code does. It involves passing data around all over the place and attaching state to objects that get constructed over multiple methods.
How do you create a low-abstraction, bottom-up codebase when every coroutine you need to write is getting turned into dozens of separate functions? I think this is showcased in the code examples that the article author critiques from Clean Code. They're littered with side effects and state mutations. This stuff looks like it would be a nightmare to maintain, because it's over-abstracted.
Martin is writing one-line functions whose entire purpose is to call exactly one other function passing in a boolean. I don't even know if I would call that top-down programming, it feels like critiquing that kind of code or calling it characteristic of their writing style is almost unfair to top-down programmers.
This reminds me of a chapter from
Clean Code by Robert C. Martin where he suggests using names from the "solution domain space" ie. CS terminology, because names are succinct and more precise which is preferred over long names that are tied to some specific domain for which the software is being developed for, which might require expertise that is disparate. The author suggests to use terminology from the "problem domain space" when "there is no 'programmer-eese'" name for it.
My team had a discussion about this and some argued that this might alienate programmers who are novices, and might be easier to use "Enlgish" but I think that if the problem space for your software is niche enough then a new team member, or a novice will have to learn terminology either way. In my opinion, programming terminologies are more precise and transferable to other programming jobs and problems in general, so is a more sustainable and relevant way of learning. It might be tough at first, and I agree the attitude of the senior dev would make a huge difference, but as long as the senior dev takes the initial confusion of the novice as a good teaching moment, and explains it patiently and clearly I think it can be more valuable in the long term.
>I would say that, unless you're just starting your career, books like
Clean Code, The Pragmatic Programmer and the like are not real "revelations".
I agree, that's why I'm asking this question. I think these particular books are mostly helpful to the junior engineer.
But it's hard to believe that from here on out the only thing that's left is to learn how to deal with people. Surely there's more to the software side of software engineering than what TPP and Code Complete have covered. Surely very experienced engineers have written books on software engineering that cover something more than entry-level knowledge. (Clearly, since I haven't found such books yet, there's a chance they haven't been written. But I find that hard to believe, considering the broad audience of software engineers that are interested in that knowledge.)
Books:
1 - Code: The Hidden Language of Computer Hardware and Software by Charles Petzold
2 - Clean Code: A Handbook of Agile Software Craftsmanship by Robert C. Martin
3 - Code Complete: A Practical Handbook of Software Construction by Steve McConnell
4 - Algorithms by Robert Sedgewick & Kevin Wayne
5 - Types and Programming Languages by Benjamin C. Pierce
Best to learn? Highly unlikely.
Interesting? Didn't capture my attention right away.
Good practices? More or less.
Advances the craft? Let's say yes.
Clean Code and The Pragmatic Programmer are both great books, but really your team needs to be doing code review on every line of code that is going to make it to production. It doesn't have to be /you/ reviewing all of it. As a bonus, having your team review each other's code builds more familiarity with the app(s) you are working on and allows all your team to learn from each other.
My favorite rule is 4.1.1; always use braces even where optional. I think a small fraction of the economy may have been damaged by the bugs caused by the silliness of leaving out optional braces and then having another developer come along and, well, you know how that goes :)
As someone who once read the Sun Java Style Coding [1] (which at a quick glance, appears to be a super set of the Google style guidelines) standard years ago and found it exciting and very helpful material, I unfortunately did not get such a kick skimming through this. Perhaps it's because after having read Clean Code [2], I feel that there is much missing that can lend itself to better code.
[1] http://www.oracle.com/technetwork/java/javase/documentation/...
[2] http://www.amazon.com/Clean-Code-Handbook-Software-Craftsman...
I recently had an on-site interview at a big SV tech company. I had 4 interviews and 3 of them flat out told me they haven't read my resume. I didn't do as well on the whiteboard hazing but I'm confident that I could have solved them if I had more than 30 minutes to come up with an efficient solution.
What disappointed me was, 3 of the interviewers had no idea about my background and weren't able to extract my strengths. Even though I am a new grad, I have interned for 2 years as an app dev and learned a great deal about design, code quality, testing and etc...
I have read Effective Java, Clean Code, and Head First Design Patterns. I'm reading Java 8 in Action now. I have not memorized them page-to-page and still need more experience to master them, but at least I know some of resources I can go to for more answers. I have participated in code reviews and enjoy them. I can implement LLRBT and many of the algorithms you can expect a new grad to know but I have not invested my time on hacker rank and uva.
I don't know what SV or big tech companies are looking for. I constantly hear interviewers say they want good engineers but fail to capture the essence of a potential good engineer well. What benefit is there in hazing anyone with problems many engineers don't deal with without the tools they use every day, and with an absurd time constraint. Kosaraju didn't come up with SCC in 30 minutes and he had a PHD. Sure I can spend hours studying for whiteboard questions but to what benefit. I am sure anyone of you can come up with a whiteboard problem you can't solve in 30 minutes, but what does that say about you.
Clean Code - Robert C. Martin: I got this book in college for a class and enjoy referring to it when I feel that my code quality is starting to decay.
Computer Principles of Modeling and Simulation - T.G. Lewis/B.J. Smith: I received this book as a gift from one of my favorite professors in college. It was published in 1979, but I find the material still relevant when it comes to introductory concepts of computer simulation.
Big Java Late Objects - Cay Horstmann: Another text from my time at college, specifically from my data structures course. I keep it because I like the way it explains fundamental data structures with well-written Java.
Head First Design Patterns - Eric Freeman/Elizabeth Robson: Another college textbook, and one of my least favorite reads of all time, but I'll be damned if it doesn't explain design patterns well enough for me to keep it around. I refer to it now and then but only when I feel like punishing myself.
Learning PHP, MySQL, JavaScript, & CSS - Robin Nixon: A dangerously outdated introductory web development text that I bought when I was in high school. It was the first programming book I ever purchased and I keep it around because I enjoy remembering what it felt like to explore web development for the first time. I've not referred to it in years, for obvious reasons, but it explained full-stack web development very well and gave me a foundation that I've been able to build on to this day. I remember standing in the tiny Computer Science section at Barnes & Noble where I found it, taking it home and cracking it open, and working through it until I had to make myself go to sleep. It's the first programming book that really hooked me.
A previous thread on HN recommended Uncle Bob's
Clean Code book. I found it super helpful as I started my first programming job.
I followed it up by reading Clean Coder for some career advice.
I think the idea of "quick starting" a new job since you have no previous professional experience may set unrealistic expectations and pressure on yourself.
They probably have budgeted on-boarding time for you to figure out some of their stack and lined up some "intro" level work to help you get acclimated.
My advice is be ready to introduce yourself and be honest with your familiarity with the tools they use. Your co-workers probably have awesome things to teach you if you just ask.
I paid a dollar for the first video and didn't even finish it. I own Clean Code and think it's one of the best programming books ever. This video series however (based on the first video) looks like it's been made back in 1994 and the presentation is too jumpy and jarring with a lot of short edits to be taken seriously.
Eric Evans'
Domain-Driven Design. I've heard enough about DDD over the years that I figured I'd just go to the source. Liking it so far, I have some good takeaways but we'll see how effectively I'm able to use the ideas over the next couple years.
Martin Kleppmann's Designing Data-Intensive Applications. Based on the frequent praise it receives here, haven't gotten far yet. I have some project ideas (for personal and professional projects) that could benefit from reading through it.
Martin Fowler's 2018 update to Refactoring. I read the original one a long time ago. In context, we have a work lunch & learn series and I'm interested in doing some presentations on the topic of refactoring (why, how, and when in particular) so it seemed appropriate to refresh my memory on some specific terminology from the book as well as to see if it's an appropriate book to recommend to colleagues. My recollection of the first edition is that I'd recommend it to colleagues, but it's been so long I'd rather read it once more before actually recommending it.
I reread Robert C. Martin's Clean Code based on some recent discussion here where it was rather strongly dismissed by a fair number of people. I didn't recall it being bad, my reread confirmed it is not, in fact, bad. Java-heavy, which is now an unpopular style of OOP, but otherwise a very good book. I'd still recommend it to junior colleagues paired with some caveats about avoiding seeing the world in black & white. There is no singular Way of Programming, but learn various ways and find what works for you and your team.
There are some more, but it's almost 5am and I haven't been able to sleep so I don't recall everything that's in the book stack or ebook queue. These are the ones I'm most interested in at present.
So, in your opinion are
Clean Code and Clean Architecture still relevant/updated?
I've come more interested in the way I think about/produce code in the last couple of months and am searching for something that might be a good read on it - considering I'm mainly a JavaScript developer.
I find that most of the concepts of SOLID, for example, are really hard to figure out in most of the code base of the projects I've worked/see online implemented in Node for example. It might be related to my lack of knowledge and understanding of said principles though, but I've seen a youtube video (
https://www.youtube.com/watch?v=CnailTcJV_U) some months ago that showed me a "clean architecture" implementation that I've never really seen in any project I've fiddled with.
I often hear that people should read Clean Code and that it is necessary in large projects. I would say that there is no direct correlation between how large and complex the business logic is and the difficulty of understanding and maintaining the code. I have seen small simple applications that are not maintainable because people have followed SOLID to the extreme.
There has been plenty said about the topic. Have you read
Clean Code? The Wikipedia page? The Pragmatic Programmer? The depth on the subject has been expanded far more than just “single responsibility”.
Here is Bob responding to OPs link: http://blog.cleancoder.com/uncle-bob/2020/10/18/Solid-Releva...
Stating:
“SRP) The Single Responsibility Principle.
Gather together the things that change for the same reasons. Separate things that change for different reasons.”
That’s a pretty clear delineation IMO.
Practice often... and know your language well.
There is a huge difference between knowing and KNOWING. Knowing your tools well enough lets you focus on the problem rather than searching how to hacking your way through. Don't be a copy paste programmer.
Don't be mislead by fast typers either.
Fast turnaround is good, but stable code is better. What's the point of finishing in 1 day instead of 2 if you'll be debugging for a week afterwards? With enough practice you'll be able to get the stable code out in the same time as the fast typer.
Some book recommendations:
-Code Complete 2.
-Refactoring: Improving the Design of Existing Code.
-Clean Code.
-Head first design patterns.
I manage a team of power plant design engineers writing complex scientific HPC software, mostly in Python (which drives Fortran 77 codes behind the scenes, among other things). It's been a long haul but through the years we've learned a lot of good lessons and are pretty productive at what I consider at least moderately good code. Everyone starts off by reading
Clean Code and taking basic proficiency training. We know to try to make code speak for itself because, as we've all seen many times, comments lie. We've slowly learned from the software engineering community how to set up things like Jenkins for CI, black for Python code auto-formatting, Phabricator for revision control policy and code review. We're writing docs in rst with sphinx, watching coverage, and getting pylint 10/10. We're waking up to the wonders of static types.
Mandatory code review has turned out to be a great way to train newbies, write better code, and make sure code is understandable to at least one other person. It's been an investment (it's slowww) but I still think it pays dividends. That's what I'd add to this advice. And I'd tone down the comments focus. Comment only when you fail to express yourself clearly in the code.
Good collection of best practices overall. I would not say they are Go-only, as I read about them 5 years ago in
Clean Code by R. Martin and another part can be found in Code Complete by Steve McConnell.
Once again, good collection if you have no time to read the book. Anyway, it does not cover other parts like contracts/interfaces, the absence of comments (which can be a good sign) etc. Would recommend checking both CC books if you want to write better and maintainable code.
PS. Anyway, Dave, thank you for the popularization of best practices.
Hey there! As someone with just half the years of experience you have... I'm just gonna leave my one cent here :-)
Clean Code is an excellent book to start going in the direction of what I'd consider "good programmer", in the sense that a good programmer writes code for humans, not for computers!
My opinion of "good programming" is just exactly that, the code is easy to read, easy to glance and figure out at a high level what it is doing.
About OOP, there are a ton of opinions regarding that (I kinda dislike it...) so don't really fret about it, a good programmer writes code that humans can easily read, that human being future you also, since a week later we often have no clue what our code does and need to read it again anyways!
Something that I've been enjoying a lot lately is investing in my tools, which for me right now is learning to use neovim, and even thought I'm not using it professionally (I think I'll never will because that might convert it into "work" and suck all the fun out of it) it has made a huge difference in my side, projects, you know, the code that I'm actually excited about!
I sympathize with you since I didn't took formal programming courses and most of the felt like I was not good, or not up to par with other or whatever... seems like my engineering manager and the previous raises disagree with me! So, don't confuse impostor syndrome with "not good"
As a last thing, I recently came across a couple of articles here in HN regarding building useless stuff[0] and homebrew tools[1], and in doing so I've been finding the joy and fun I used to have back when I was just learning!
So bottom line, don't worry about being good and focus on having fun/enjoying what you do!
[0]https://news.ycombinator.com/item?id=27256867
[1]https://news.ycombinator.com/item?id=27482397
1. Learn to be criticised and to gain as much knowledge from that, as possible.
2. Learn to fail and feel good with that. And as above, to gain as much knowledge from that, as possible.
3. Learn to be confident enough to defend your solution.
4. Read as many non stricly technical books related to programming as possible. Ie. "The Pragmatic Programmer", "Rework", "Clean code", etc.
5. Don't take your job too serious. If you worry about your code after hours, stop! And if you can't, change your employer.
6. Everyone makes mistakes. Just try to not repeat them.
This is an incredibly broad question and touches on many aspects of software engineering, devops and operations. For operations, I would recommend having the team read the google SRE book
https://sre.google/workbook/table-of-contents/ it has everything one would need to setup a modern operations infrastructure and associated best practices.
https://sre.google/workbook/table-of-contents/Sounds like you are unhappy with the quality of code and error handling. Seems like it was written by junior devs? I would recommend having the team read the usually recommended books if they haven't. At the bare minimun:
* Refactoring by Fowler
* Clean Code by Robert Martin
If you are using an OO language:
* Practical Object-Oriented Design in Ruby
The book has "in Ruby" in the title but it's a general purpose book on what make OO design "good"
Then follow it up with
* Patterns of Enterprise Architecture
* Clean Architecture
These books are not perfect or the be all end all, there are parts of them that might be slightly dated but they get you to a large chunk of the way to the promised land.
Lastly, if the application is working, the users are happy, there is no bug infestation and you are not having issues with releasing new features, don't feel the pressure to immediately "fix" the code.
To gain some context, I would suggest reading the Legacy Code book by Michael Feathers or read about Kent Beck's 4 rules of simple design, or even read the
Clean Code book.
I think the first thing to consider in doing a review is first look to see if the code is easy to read and understand. There is that number out there that states we read code ten times more than we write it.
Hey, these are good questions.
> Aren’t the first 3 or 4 chapters basically what you can find in Google’s own cloud toturials?
> Why does the domain-driven-design chapter come after you’ve tied the reader into GCP? I can’t think of a single enterprise business domain where that would make sense from a European GDPR driven perspective.
Our idea was to create a seemingly modern app based on microservices, with full GCP setup and fancy tools used. We then go on to point the issues in the code. We wanted to show how an app that seems well built on surface can have hidden problems that are hard to spot. We don't deep dive into GCP, mostly just describe the setup.
> Why do you think you can cover that many topics in a single book? I mean, part of the reason Clean Code is well liked is because it covers one topic in depth, rather than covering a bunch of different topics without ever giving the reader anything of value on any of them.
I believe you'll find a lot of value on these topics, even if we don't go super-deep into each of them. It should give readers enough ideas on how to approach building complex apps. We base this on our experience, so it's not just bland descriptions of the patterns. Also it's all focused on Go and on a real example project, so it's not abstract.
Short term solution : Lead by example, a good chance that they can learn from those and maybe copy them afterward. But the code quality will improve. This can take your time but as long as you have several good examples, you can reuse those.
Long term solution: Encourage them to watch conference and good books like Clean Code, or TDD books. Those are incredibly good. Maybe they are not interested in at first, and never, but those who want to be better will become ones.
I bought this book off the back of the referenced discussion trashing
Clean Code. Whilst
Clean Code has its problems, well articulated in that previous discussion, I am loathe to recommend this book. A large part of it is dedicated to commenting practices and seems a bit out of touch with the way software is developed today. There were some rather dubious claims on TDD as well, suggesting that it aims to 'get features working, rather than finding the best design' which seems to completely ignore the refactoring phase practised in a TDD cycle. A choice quote about comments that I strongly disagreed with: "without comments, you cannot hide complexity". The book also strongly advocates for large classes and considers small ones an anti-pattern called 'classitis'.
I'd say half the book contained good advice, the other half was mediocre or dubious at best.
I'm curious to hear what others think who've read both books.
Now this is usually in my opinion not a good advice (it is like reintroduction of global variables) as unnecessary state certainly makes things more difficult to reason about.
I have read the book (not very recently) and I do not recall this but perhaps I am just immune to such advice.
I like his book about refactoring more than Clean Code but it introduced me to some good principles like SOLID (a good mnemonic), so I found it somewhat useful.
You should expect some pushback on your pull requests, particularly early on. It’s a good opportunity to learn, and a good sign that your team cares about code quality and continuous improvement.
You mention bugs specifically, for which I think the best remedies are good unit tests and careful consideration of edge cases (which often go hand in hand). Other smaller issues such as deviation from framework conventions and performance problems can be helped by getting to know your languages, frameworks and database better, which comes with time. More generally, there are lots of good resources out there to help you improve the readability and structure of your code - Clean Code by Robert Martin (particularly the earlier chapters) and Sandi Metz’s books and talks are both good starting points. Issues with your general approach to solving problems are harder to address, but reviewing others’ code, learning about design patterns and pair programming can all help here.
In terms of actionable advice, I’d encourage you to briefly discuss your intended approach to a problem with a colleague before starting work: this can help expose issues in advance. Even better, pair program on the implementation with another engineer. Just pairing on the review can also help to reduce the back and forth and get code shipped faster.
Off the top of my head:
- Reading books (e.g. Clean Code, Refactoring: Ruby Edition, Practical Object-Oriented Design, ... these left a mark)
- Going to conferences (Rubyist? Attend a talk by Sandi Metz if you have a chance)
- Testing (TDD at least Unit Testing)
- Yeah, the usual stuff: quick deployments, pull requests, CI/CD ...
- Preferring Composition over Inheritance (in general and except exceptions :)
- Keeping on asking myself: what is the one responsibility of this class/object/component?
- Spending a bit more time on naming things
- Have a side-project! It's a fun way of learning new things (my current one is https://www.ahoymaps.com/ - I could reuse many things that I learnt also in my 9-5)
Code Complete, Clean Code, and Debugging were profoundly educational to me as a junior developer. The Obstacle is the Way helped me deal with personal issues, but it's still a work in progress. The Joy of Less was a great introduction to minimalism. I just started reading Neuromancer but its got me hooked on the scifi/cyberpunk genre.
There's a word, in other comments, that I expected to find: zealots. Zealots aren't sufficiently critical, and they don't
want to think for themselves; a reasonable person should be able to, and a professional should be constantly itching to, step back, look at code, and decide whether some refactoring or rewriting is an improvement, taking a book like
Clean Code as a source of general principles and good examples, not of rules.
All the "bad" examples discussed in the article are rather context dependent, representing uninspired examples or extreme tastes in the book rather than bad or obsolete ideas.
Shredding medium length meaningful operations into many very small and quite ad hoc functions can reduce redundancy at the expense of readability, which might or might not be an improvement; a little DSL that looks silly if used in a couple of test cases can be readable and efficient if more extensive usage makes it familiar; a function with boolean arguments can be an accretion of special cases, mature for refactoring or a respectable way to organize otherwise repetitive code.
Great, but that's not the reason why obvious comments are bad. They are bad because it's not maintainable. For you this means that the next time a developer refactors the code, you need to check if the comment is still accurate with the refactored intentions. I repeat, this is not maintainable! I love how the book Clean Code described it: "A comment is a failure to express yourself in code." There are situation they are useful, but those are definitely not obvious comments.
Oh god, I've been there too. It's like watching code cancer develop and I'm helpless to stop it. Maybe if they can name an anti-pattern for this that can be readily referred to. I usually try to refer people to Clean Code by Robert C. Martin. But everyone presupposes they are smarter than me and old guys like him and smarter than the people who already wrote and tested and attained widespread adoptance (word?) of whatever library or framework already does this stuff he's re-writing. I've come to believe its an attempt to establish job security by writing vast tangles of custom code all their own. Trouble is when you have non technical managers who see him churning away - checking in loads of code and spending hours 'fixing' bugs (he introduced himself) so on paper he comes out looking way more 'productive' than others - so he becomes a darling.
Highly recommend starting with "The Pragmatic Programmer". I found "
Clean Code" to be much more narrow in its applicability (and I did not enjoy Martin's writing, but that's highly subjective).
The Pragmatic Programmer serves as inspiration for me every time I read it. I know everything in it, but somehow I always come away with at least one "I could totally be solving my current problem with this!" insight from a re-reading.
I like
Clean Code and Code Complete.
Clean Code has a narrative and is opinionated. It explains the experiences that formed those opinions. It is a better read.
Code Complete is dry, academic, and comprehensive for its scope. It references many studies and is well documented. It has opinions too of a sort. It is a better reference.
Thinking of function length - Clean Code says short functions are good. Code Complete references studies that say it is not long functions that are bad, it is functions using too many objects/variables that are bad. This of course has an indirect effect on function length. So I keep this in mind, and both books are helpful.
I read a bunch of Uncle Bob's books and usually don't mind him being opinionated, although I did think the opinions in Clean Coder got to be too much. Although not all of it. Recently I have been mulling the idea from that book that there should be zero regressions. I think there is something to that, if you start to accept there can be 2-3 regressions per sprint, then why not 5-7? Why not 10? I agree with him that acceptance of regressions is a problem.
I read the same thing in "
Clean Code" (amazon:
http://is.gd/mJ8g )
I have two objections: First, what is "one thing"? Render a Doom 3 frame? Or increment the "i" variable? The "Clean Code" author argued that a log statement or a try/catch statement deserved its own method.
Second: says who? Where's the evidence that doing "one thing" is better than doing more things?
In general I notice that there are many rules and best practices in programming, without a lot of evidence, or even discussion of the drawbacks.
(Not parent)
Having read both a long time ago, I also feel like Code Complete is the one to recommend: it covers more ground, is pragmatic, and more importantly most of its recommendations are based on studies, i.e. they come from empirical evidences. Clean Code compares poorly to this, in that it's just one guy's opinion.
That doesn't necessarily mean Clean Code is a bad book, but since our work relies primarily on logic, I'd rather have arguments presented to me logically.
Since both books cover pretty much the same ground, it makes more sense to recommend Code Complete.
I agree with your premise that
Clean Code is not a suitable book for all programmers / and or all languages. But a good amount of "enterprise" software is written in Java. And, in "enterprise land" (where I currently live), there are lots of mediocre, inexperienced or untrained programmers for whom the advice in
Clean Code is useful.
I have had to try and clean up functions that were two thousand lines long (in Java), had lots of side effects, and took in seven parameters. Oh boy did I wish the developer had read Clean Code.
I agree with your premise that the book is not relevant to those who work in dynamic or functional programming languages. Frankly, I don't think they are not the intended audience. I think it is a little hyperbolic to call it the "one of the most dangerous programming books released in the last decade".
I would argue that what makes code "good" is completely subjective which is why I don't spend too much time thinking about it.
The only criteria I have for good code these days is "Does it work", "Can I understand it". Everything else is a good IDE's command away for being willed into reality. So I really don't spend too much time on the "good" code debate like I did as a teen reading "Clean Code" and GOF books. I actually wish I could have that time back, I would have read, in their place, books on type theory and OS design, Posix, in other words things that actually help me build stuff and get things done and that I subsequently had to read later. Undo the damage done by the "good code" people that have me thinking about stuff that nobody cares about. Take a month off, read a book on game design in opengl, and write a cool robot simulation or something and remember how much more gratifying that is than writing a small do-nothing program just to try out some useless design pattern that doesn't scale beyond micro-examples.
There is so much varying lit out there on how to write good code that I am surprised that I am surprised if even 2 programmers can truly agree on what good code is. So Again, I'll say that "good" when it comes to code should be equivalent to "easy to understand" and "does the flow of text match the flow of program execution" in other words "is it easy to understand given I am familiar with the problem domain".
No, it isn’t that black and white. Many of Martin’s suggestions are silly, especially when applied to languages that are more expressive (like Ruby, CoffeeScript) or otherwise have no relationship to Java.
I distinctly remember arguments with people who were reading Clean Code at the time who really believed that one-line methods really were the ideal.
The trick is knowing what does “doing more than they should” actually mean? If you follow Clean Code as I’ve seen some people follow it (including the Ruby dev shop I mentioned elsecomment), you will end up having substantially larger interfaces at the cost of understanding just what it is that your program is supposed to do in the first place.
I’ve dealt with programs written the Clean Code way (an explosion of methods, classes, and objects), as well as programs written with too much going on in one place (e.g., 2+kloc functions). Neither is fun to deal with, but it’s generally easier to assimilate the basic business purpose of the 2+kloc function than something that has a larger interface surface than it needs to have.
Thanks everyone, the comments are much appreciated. Here's a list of books and other media resources recommended so far in the thread:
Robert C. Martin, Clean code: https://www.amazon.com/Clean-Code-Handbook-Software-Craftsma...
Vaughn Vernon, various: https://vaughnvernon.co/?page_id=168
Steve McConnell, Code Complete: https://www.amazon.com/Code-Complete-Practical-Handbook-Cons... 2
Clean coder: https://cleancoders.com/ videos
Hunt and Thomas, The Pragmatic Programmer: https://www.amazon.com/Pragmatic-Programmer-Journeyman-Maste...
Hitchhiker's Guide to Python: https://docs.python-guide.org/
Dustin Boswell The Art of Readable Code: https://www.amazon.com/Art-Readable-Code-Practical-Technique...
John Ousterhout, A Philosophy of Software Design: https://www.amazon.com/Philosophy-Software-Design-John-Ouste... This one looks particularly interesting, thanks AlexCoventry!
Kent Beck, Test Driven Development: https://www.amazon.com/Test-Driven-Development-Kent-Beck/dp/...
Dan Bader, Python Tricks: The Book: https://dbader.org/
Ian Sommerville, Software Engineering: https://www.amazon.com/Software-Engineering-10th-Ian-Sommerv...
Svilen Dobrev, various: http://www.svilendobrev.com/rabota/
I usually recommend a few different books:
Clean Code: A Handbook of Agile Software Craftsmanship
http://amzn.to/2vcRcgU
This book really helped me focus on code organization and seeing maintainable code as an overall goal whilst building long-term applications. I'd say that one of the reasons why the work I've done 3-4 years ago can still be used, expanded, and maintained today is because of this book. Short functions, code organization, and naming conventions all stuck with me.
I'd say that unlike other programming books, this one focuses on the "art" and "organization" rather than syntax and other aspects of programming.
The Pragmatic Programmer: From Journeyman to Master
http://amzn.to/2vfeUaT
This book tackled real-world application building and practices. I'm still reading it. I liked how it tackled not only some basics of programming (resource management practices) but also project management to a certain extent. Eg. how to use prototypes, how to use "trace bullet" programs, etc.
Game Programming Patterns
I think one of my favorites has been "Game Programming Patterns" http://gameprogrammingpatterns.com/ which is free online or you can get an ebook/print version http://amzn.to/2veRdiO
The book introduces several basic design patterns, it explains WHY they're used, how to implement them, etc. in the best way I've read so far. No CS book or online article has been able to explain these patterns as this book did.
And I'm not even a game developer.
Also, check out this post on dev.to -- https://dev.to/ben/what-are-the-most-interesting-readable-so... it has some good answers! :)
I've had a near identical experience over the last 30 years. Every point in the article rang true and I sympathise with every one of them.
Regarding the second point: One of the hardest things to swallow is a programmer with 2 or 3 years experience pointing out code smells in my work simply because he's read Clean Code (I've been a professional, full time programmer for 30 years). Sure, there are code smells in my work - I won't deny it - I'm not a clean coder and I accept that my coding style leaves a lot to be desired. But I work hard and solve difficult problems to a clients satisfaction.
Is it just me or does anyone else think that 'code smells' is a demeaning expression?
I think the flow you write should always be the way you work with code. First make sure it works, then look how to improve it, what parts are expressing similar behavior, what parts are different etc. If I remember correctly this is also what Robert Martin advises in
Clean Code [1]. And it makes sense, worrying too much over what the abstractions are going to be is only going to slow you down.
I normally go even a bit further (certainly on the frontend) and leave duplication until I wrote something 3 or 4 times (or until it has stayed there for a little while). This ensures that when I do write my abstracted component I'm actually making sure it is something that can, at least within that app, be re-used.
I do re-use React components between different projects but am also using the same Bootstrap theme so this makes a lot of components really easy to re-use.
[1]: https://www.goodreads.com/book/show/3735293-clean-code
>
Maybe there should be a new edition of Clean Code written specifically for FPI’ve posted links to this work-in-progress book a few times in the past, but I’m going to do it again because I think it fits the description perfectly.
Grokking Simplicity by Eric Normand [0] is a great book for introducing the premise behind FP in a pragmatic fashion. It doesn’t get bogged down in monads and type theory, just the benefits of pure functions and modeling applications as flows of data.
All the code examples are in JavaScript, so it requires no prior knowledge of functional programming, and it does a great job of building things up from first principals while highlighting the benefits vs a more object oriented approach.
It’s only half complete, with a nebulous completion date, but I’ve already purchased a copy, and it would the first book I’d recommend for any newcomer to FP (it’s already worth it just from the first half as far as I’m concerned).
[0] https://www.manning.com/books/grokking-simplicity
That's interesting, I had the complete opposite reaction to clean code. As a person that recommends this book, with full heart, to every developer, I'd like to hear any details you could spare re: why you believe it's damaging? Maybe you can provide some examples of well-written codebases and why you believe they're such? And maybe you could comment on why you feel Clean Code's principles harm readability with some examples?
I find it painful working with codebases that don't use most of the principles re:
- Write code like good stories: Code should read like a story, methodically descending the call graph method by method; each working at one level of abstraction.
For example, why is string manipulation littered all over this function that's supposed to be dealing with consolidating reports? Ugh. I like when one function stays at one level of abstraction
- Factor out conditions into descriptive methods: I shouldn't have to sit and read through 5 logical operators, some arithmetic, and method calls in 1 'if' conditional, to understand why we're doing all this.
Once again, this goes back to having your code read like a story. Factor it out into a descriptive function, so that I can understand at a glance and deep dive if necessary.
- Comments are a failure: This applies 99.99% of the time. It's almost comical when someone leaves behind a comment that could be eliminated by factoring something out into a descriptive method call instead.
There's a lot of other great stuff in Clean Code that I'm forgetting off the top of my head. (It's been awhile since I last looked over it.)
I've come across very few code bases that are a literal pleasure to read. https://github.com/jekyll/jekyll is one of the cleanest codebases that comes to mind immediately. And on the other side of the coin, https://github.com/kubernetes/kubernetes is one of the dirtiest.
If anyone wants more details/expansion, let me know and I'll reloop. (On my phone right now.)
My top down approach for writing software design docs:
1. Business objectives
2. Users and use cases
3. Architecture <- design decision, performance expectation, wide picture of the system
4. Infrastructures <- you may mention environment and networks here, like k8, aws or gcp.
5. Application <- ui, flow, activity diagram, algorithm here
6. Data <- now you can place UML here
As for code level documentation, writing readable codes is enough as documentation. If some guys can understand what the codes do by reading the codes, documentation won't be needed. How to write readable codes? A good reference for this is Clean Code book. If documentation is really needed, Java Doc style is worth to follow.
Hope this helps
Thanks for the pointer to Ousterhout, I don't think I've heard of him before but a lot of the Tcl people have put out good stuff.
Uncle Bob and friends definitely form their own "school". I think they call the "functions and assignment" style "Newspaper style", since for them it's kind of like reading a newspaper. Following it you can actually get a long way towards the dream of "self documenting code". I'm happy when people who believe in some specific school of thought get it to work for them, and even if I disagree on things at least there's consistency.
It's still never as clear as a literate program, though. And while Uncle Bob has been upgrading by learning Clojure, a lot of that school's work has assumed OO-in-the-style-of-Java5/C++98 environments. And to be fair that's a lot of the mass of legacy code we unhappily get saddled with. I think their work is less applicable and there are other schools to listen to when you have different languages or programming methods (FP, declarative, OO with a MOP, etc.).
I read the Clean Code book finally not too long ago, and while I've never argued with a book so much, there is value in it, and some programmers would do much better than their current flailing to follow its approach exactly. But these guys aren't my personal programming heroes, I'd rather be like a Norvig than a Jeffries (even if the latter is a perfectly acceptable engineer). But I can usually find value in all their works; philosophically I'm aligned with Bruce Lee, I'll take what I think is valuable and discard the rest.
"I don't know if I'm just looking too far into your comment, but I don't see why you're blaming Netflix (or it seems you are) or how you got to them being the bad guys for this? They're not the ones that make the content. If it was up to Netflix, they would just release their shows DRM-free on Netflix for any platform. Unfortunately, that's not how things work and they have to bow to the demands of the content distributors (not creators, like some people have stated in other comments)."
We did a book study on a book called Clean Code where I work, and I reminded of a similar situation that the book explains when describing why we all write dirty and bad code.
Why do we write bad code? Because our stakeholders and our product owners require it. Well, they push deadlines and expectations on us that mean we have to cut corners to make their promises become reality within the unrealistic time provided.
But if you ask the stakeholder why they pust that on you, the stakeholder will say "well, it's the client". Or they'll say "marketing made a promise to the client".
It's always upstream. There's always an upstream concern.
In the book they talk about making a stand, as a developer. That you have a responsibility to explain to your stakeholders and the people above you that doing something the RIGHT way is worth it. That you are the subject matter expert, that it is your responsibility to raise these concerns and thus your responsibility to write good code.
Netflix can pass the buck. "We do what we have to".
But they have a responsibility as one of the premiere web companies to do more than pass the buck.
A Good Internet doesn't happen accidentally, and it doesn't happen when stakeholders pass the buck. It happens when people make a stand for what's right and operate according to their values.
So yes, it is Netflix's responsibility not to bend Mozilla into accepting a Studio's IP demands, but to bend the Studio into accepting humanity's internet demands.
Why do we assume that Netflix can persuade Mozilla, but not a rightsholder?
I’ve read both books. I consider Ousterhout’s to be one of the better recent books on software development, though as mentioned in my other comment, this is more because of the earlier content than the later chapters. I have been critical of
Clean Code since before it was cool and I actively recommend against junior developers reading it.
I would have liked to see Ousterhout make a more thorough argument if he was going to criticise TDD. His central criticism — that TDD results in what he calls tactical programming, prioritising the implementation of specific features over good design — is certainly defensible. However, I think he was too superficial in what he actually wrote on the TDD section, and consequently I don’t think he made a particularly convincing connection with the ideas developed earlier in the book.
I think you’re slightly unfairly misrepresenting his position on large or small classes. He makes a solid case that what he calls deep modules are better for managing complexity than shallow ones. He also identifies a correlation with size because small modules tend to be shallow. That’s not the same as arguing for large classes or against small classes just because of their size, though.
It sounds to me like you haven't internalized a lot of the advice in the first half of "
Clean Code" and/or the entirety of "The Pragmatic Programmer". Either of those books takes a few weeks to read slowly and a few months-to-years of deliberate practice to internalize and synthesize as your own. The good news is that admitting you have a problem is the first step.
Personally I find I still frequently write pretty atrocious code on the first draft, and it's only by stepping back from the problem after demonstrating to myself I understand it well enough to solve it at all that I can begin to write a more graceful solution. But deadlines and reality being what they are, I think the majority of us are embarrassed by our past code a majority of the time.
So don't be too hard on yourself, but also frankly don't worry about shoe-horning yourself into "A Career" either. They're kind of a recent invention and the whole concept might need a few more iterations. You could spend a few years as a Product Manager, an Engineering Manager, a Highschool Teacher, or a Business Analyst, leveraging your past experience to gain competency in a new niche.
I want to emphasize of self-awareness you have is commendable and not universally present: If you can realistically assess your own current skill level and then apply yourself to improving, you could be an above average software engineer before you know it. And right now it seems like so so many companies just can't get enough software engineers, so it's a pretty safe place to practice learning how to learn while also earning a decent income.
I remember reading this here a while back - wonder what happened:
https://neil.fraser.name/news/2015/04/13/But like others in this post I would recommend CS unplugged.
And depending on how long he is in there for he might want to look at:
How to Design Programs - This is a good book, and although it's in Scheme, it teaches how to create appropriate levels of abstraction, which seems to be something many programmers struggle with.
Concepts, Techniques & Models of Computer Programs - Discusses the different paradigms and how they are inter-related.
Also something a bit more vocational like The Pragmatic Programmer or Clean Code / Clean Coder probably wouldn't hurt either.
If he can read all of those he will be very well prepared to do some actual programming when he gets out.
SICP not a bad shout either, although I've not got past the first chapter.
I like to read a bit after dinner when my kid goes to bed. It's much nicer than looking at a screen after I come home from looking at a screen. And I like reading tech books better than blogs anyways - I find that a lot of stuff online just regurgitates what classics like
Clean Code are saying, but less eloquently.
The only downside is that reading books doesn't help you learn new languages or frameworks.
Screw the github graph.
No problem!
I did read Clean Code by Robert Martin. He's definitely in the "die hard TDD guru" category, but there are still useful examples to be extracted from the book.
Besides that, I mainly learned a lot of testing tricks in the wild, reading through Github projects. My learning process now-a-days is mostly:
1. Discover a really cool trick or concept I didn't know existed in a Github project.
2. Research the hell out of it.
3. Try to use it in some personal example project.
You can set up a weekly code review where you take turns letting each developer present a piece of code they wrote to the team, and then discuss and give feedback about that code.
Also direct them towards resources where they can learn clean code practices. Perhaps institute a monthly "book club" where you select books about good coding practices. I would suggest starting with Clean Code by Robert Martin
I'm completely with you here. Until I read
Clean Code, I could never really figure out why my personal projects were so unreadable a year later but the code I read at work was so much better even though it was 8 years old. Sure, I probably took things too far for a while and made my functions too small, or my classes too small, or was too nitpicky on code reviews. But I started to actually think about where I should break a function. I realized that a good name could eliminate almost all the comments I had been writing before, leaving only comments that were actually needed. And as I learned how to break down my code, I was forced to learn how to use my IDE to navigate around. All of a sudden new files weren't a big deal, and that opened up a whole new set of changes that I could start making.
I see a lot of people in here acting like all the advice in Clean Code is obviously true or obviously false, and they claim to know how to write a better book. But, like you, I will continue to recommend Clean Code to new developers on my team. It's the fastest way (that I've found so far, though I see other suggestions in the comments here) to get someone to transition from writing "homework code" (that never has to be revisited) to writing maintainable code. Obviously, there are bad parts of Clean Code, but if that new dev is on my team, I'll talk through why certain parts are less useful than others.
Robert C. Martin's
Clean Code book has a great section on comments:
- The proper use of comments is to compensate for our failure to express ourself in code. Comments are always failures. We must have them because we cannot always figure out how to express ourselves without them, but their use is not a cause for celebration. So when you find yourself in a position where you need to write a comment, think it through and see whether there isn’t some way to turn the tables and express yourself in code.
- The older a comment is, and the farther away it is from the code it describes, the more likely it is to be just plain wrong. The reason is simple. Programmers can’t realistically maintain them.
- Comments Do Not Make Up for Bad Code! One of the more common motivations for writing comments is bad code. We write a module and we know it is confusing and disorganized. We know it’s a mess. So we say to ourselves, “Ooh, I’d better comment that!” No! You’d better clean it! Clear and expressive code with few comments is far superior to cluttered and complex code with lots of comments. Rather than spend your time writing the comments that explain the mess you’ve made, spend it cleaning that mess.
```
// Bad:
// Check to see if the employee is eligible for full benefits
if ((employee.flags & HOURLY_FLAG) &&
(employee.age > 65))
// Good:
if (employee.isEligibleForFullBenefits())
```
I know but different people learn and keep up to date in different ways (or not at all) so for me it is not a yes/no criteria on whether they get hired/approved by me. Just another piece of data to evaluate on.
And similarly unfortunately the majority I encounter don't read many if any books. If people only read books then that is perhaps an issue as well. And reading a specific technical book about a specific software version is also usually a waste of time in my opinion. Read howtos online and experiment away instead.
I do tend to interview more mid-to-senior level of which how they keep up to date is more relevant. I am not expecting new grads to have read the entire backlog of Pragmatic bookshelf if any. Nor am I expecting anyone to have read the bricks (gang of four, Fowler's application patterns etc) cover to cover. But for example seniors not having heard of these bricks or the Clean Code and Pragmatic Programmer books is a red flag. If they know of them but disagree with them then that is fine, but not heard of them at all is weird.
In a previous job they sent me Clean Code and a couple of other books in the post to read a few weeks before I started. Which was a good sign that I was joining the right company, even if I had already read them all previously :)
Author of the article here.
That's primarily the reason why there are no "concrete examples", because one person's concrete example is another person's definition of contrived. Splitting hairs over some toy example wasn't something I thought would buttress the ideas presented, though I can imagine why some might need that scaffolding to follow along.
Re resting - here are some points the article makes about how smaller functions can in some cases hurt testing:
1) "Furthermore, when the dependencies aren’t explicit, testing becomes a lot more complicated into the bargain, what with the overhead of setting up and tearing down state before every individual test targeting the itsy-bitsy little functions can be run."
Disambiguating this for you, one of the myths of smaller functions is that they are easier to test. The article makes the claim that this isn't always true, because many who wax lyrical about the beauty of smaller functions also champion for fewer arguments to be passed to the function. The book Clean Code very explicitly states this (read the book, not as a how to guide but as a cautionary tale), and many a time what I've seen happen in the wild (especially in Ruby) is that programmers who like small functions and don't like making deps explicit - which then means the code (and ergo tests) rely on setting up shared global state.
Of course one can write smaller funcs with fewer args and not do this, but that's not the point here. The main argument is that making functions smaller doesn't always make it easier to test.
The article also does provide two examples when having the smallest possible function does help in testing. I'm not going to rehash those arguments again here.
Syntopic reading can be really rewarding. For example, once you read Thinking Fast and Slow, and a few of Taleb’s books, suddenly you notice implicit and explicit references in virtually every business book published later than those.
A similar effect can be found with Grit, Fogg’s Behavior Model, Superforecasting, and most Gladwel books.
On the coding side, I’ve only noticed this with Pragmatic Programmer, Clean Code, and maybe Phoenix/Unicorn project. Could I don’t read enough of those or they’re too focused on specific technologies instead of broad ideas … or I get too much of my technical reading from blogs and twitter. Those do get repetitive and you quickly find common patterns, but no titles to refer to.
I think the central thesis of Clean Code still holds up. You should never mix layers of abstraction in a single function.I agree up to a point, but I find this kind of separation a little… idealistic? I prefer the principle that any abstraction should hide significantly more complexity than it introduces.
At the level of system design, there probably are some clearly defined layers of abstraction. I’d agree that mixing those is rarely a good idea.
But at the level of individual functions, I have too often seen numerous small functions broken out for dogmatic reasons, even though they hid relatively little complexity. That coding style tends to result in low cohesion, and I think the cost of low cohesion in large programs is often underestimated and can easily outweigh the benefit of making any individual function marginally simpler. If you’re not careful, you end up trading a little reduction in complexity locally for a big increase in complexity globally.
Maybe its just me, but asking this question to HN readers is your answer in itself. I personally can't thin of too many colleagues of mine who read HN, let alone other programming blogs/aggregators (programming.reddit etc).
Personally, I read a lot, and write some code. I need to write more code than I read, but its a good start. And a lot of what I read does not have to be necessarily technoloy specific, rather books like "Clean Code" and "Code Complete", Intro To Algorithms etc, patterns, architectures etc.
I also tend to read a lot of self-help (GTD), business (Good to Great) and career specific books (Career Intensity) and similar blogs and sites.
In my experience, it helps to try and really really practice something. As Bruce Lee once said, "I fear not the man who has practiced 10,000 kicks once, but I fear the man who has practiced one kick 10,000 times."
To give you an example, I am currently reading Clean Code, and one of the pieces of advice is "A method should do one thing, and one thing only". Nothing new there, but normally I do take the time and effort to keep my code short and clean, but this book says that exception handling (in Java) IS ONE thing. So your method should not attempt to do exception handling as well as some other piece of functionality. For the past 3 days at work, I have tried to do that, not because the book says it, but because I did not think of it that way, and I want to give it a whirl before I make my mind up.
A lot of people I know don't read, and even those who do, don't practice it. If you want to grow - learn, practice, measure, then either accept it, or throw it away.
Update - Other HN readers have other pieces of advice that I did not add here. But working sample projects, reading documentation, tutorials online (I refer to them as the magazine version of tech books :D) all help
In reverse chronological order..
The Earth is Enough (recommended if you like trout fishing)
Clean Code (recommended if you want to invigorate your desire to write better code, there was a lot to both agree and disagree with though for me anyway)
Game Engine Black Book: Wolfenstein 3D (recommend if you want to study the details of an early 3d game engine, or details about the 386 that made it so hard to do games with)
Miss Kobayashi's Dragon Maid (this is the first manga series I've read, because I was obsessed by the anime for a while and wanted more, so would only recommend if you like the anime)
Land of Lisp (only recommended if you want a fun sort of scheme-ish style approach to seeing some of the features of common lisp in a simple mostly text based games setting)
The Age of Em (recommend if you want a careful and detailed analysis of what a possible future looks like should humans get mind uploading technology)
A Critique of Democracy (recommended if you want to have a chance of winning bar arguments, not the best for deeper thinking)
The End of Eternity (fun sci-fi from Asimov)
The Three-Body Problem (book 1 of (I found out after starting (again)) 3 -- good enough that I'll read the next two, but not good enough that I had to go out and get the second book immediately like other series I've read)
Beyond Happiness (meh, wouldn't recommend)
Ninefox Gambit (book 1 of (I found out after starting) 3 -- if you like "armchair playing war" sci-fi you'll probably like this more than me, but I'll get and finish the next two books at some point)
More detailed short thoughts + older reads if desired: https://gist.github.com/Jach/1610886 Maybe I'll wrap up one of the several in-progress ones before the month is out, too.
Scala with Akka, and RabbitMQ for scaling across multiple servers. This would be a bit more work up front than a web framework like Django but it would be more maintainable in the long run due to the fact that Akka encourages writing simple loosely coupled code that does one thing (Single Responsibility Principle). Even more important is to get the dev team working using TDD (Test First Development) and provide a proper vision to guide them. Things like Uncle Bob's
Clean Code book, and the raw, original Agile manifesto before it got sucked into the Scrum and XP methodology machine. Even though the code is more functional than object-oriented, the SOLID principles still mostly apply.
Some alternate choices that could be OK if you can find at least one good developer to lead the team, are Clojure, or Erlang/Elixir. With the Erlang virtual machine, RabbitMQ would not be necessary, although I like it because it gives you a lot of points where you can measure/monitor the internals of your application. I would also seriously look at adding Apache Camel to the mix even though Akka does not require Camel to integrate actors. But Camel is a thin layer that makes it easier to reconfigure integration points.
I agree,
Clean Code was the most important book for me too. But I wouldn't follow it blindly. Also, it's less useful for non-Java and much less useful for non-OOP languages (it's ok to have a focus, but one has to keep in mind that sometimes, certain idioms, best practices or design patterns are actually workarounds around the limitations of Java).
My favorite example: Overdoing the short functions thing. I've seen this a lot. Unsurprisingly, considering that for most devs, when you ask them what makes good code, "short functions" seems to be the first thing that comes to mind.
Splitting code into extremely short functions has a few disadvantages too: a) in what order they're called is not immediately clear, b) where they can be called from is not immediately clear, c) going up/down the stack can make it harder to follow when debugging interactively. d) It increases the LOC and noise. And e) especially in OOP languages, short methods make it more tempting to turn variables into attributes to avoid passing them around explicitly (bad due to longer lifetime).
Splitting functions should only be done if it makes sense semantically. Each function should make sense on its own. If some logic is highly cohesive (e.g. because it implements a specific algorithm), not independently reusable, and it's subblocks only make sense in one order, and it all fits on a few screenfuls, it might make sense to keep it in one longer function instead of dividing it into fairly arbitrary chunks.
There are better ways as given in Robert C Martin's excellent book,
Clean Code. He constantly refers to code taken from the Fitnesse repo and shows how the code looked before and after refactoring and testing.
I do agree with the sentiment that real world code examples are more useful. When I was learning design patterns during my degree, we were actively discouraged from using Head First as THE reference even though it did simplify things. Our lecturer was later challenged on this view. He then took the students on a counter challenge to refactor and redesign code from real world examples (taken from students' projects). Reality hit quite hard for a lot of us as we struggled to see the patterns in less obvious situations.
An interesting point to note however, was that after gaining an understanding of the design patterns at a practical level, I could then reference simple examples as given in Head First and immediately formulate how I would use it to solve a practical scenario that I might have been stuck with. Funny how it worked one way but not the other.
Programming is a trade of great skill and requires enormous amounts of knowledge. Whereas one has to be self-taught it doesn't mean one is alone. It is something I found out when I got my first job.
I joined a small team at a startup. Those guys did their best to make me produce quality code as soon as possible. They were reviewing my code several times a day, and teaching me what to do to, to make it efficent, easy to understand and well designed. Early on they even made me read the "Clean code" and I am eternally grateful for this.
Now I think part of being self-taught is actually having to find teachers on your own. Software Engineering is always about knowledge - whenever you code, you're probably solving a problem, which hasn't been solved before. Otherwise you'd just use some library to do the trick. It means that programming is about inventing new stuff, and so when you tell someone about your code, you're actually teaching them about it. Whenever you join a new project, someone has to teach you how to work with their system. If you're independent contractor building software for your client, you have to learn their ways of doing business.
High tech jobs are all about knowledge transfer, this way or another.
During my college I didn't learn that much from my professors, when it comes to software engineering in the trenches. I did learn a lot during college though. It was a time of meeting other people who were passionate for technology. We could exchange our insights, and do college projects our way. We would give each other feedback on our work, and so we were actually teaching each other.
I think above applies to meetup groups, code retreats and similiar initiatives. Programmers gather together to learn. Software engineering is all about knowledge transfer, and you have to want to learn, but it doesn't mean there's nobody to teach you. You just have to find your teachers on your own.
You are self-taught, but never alone!
I agree with several other users on this thread about maintaining existing code. If you aren't already working in a position in which you have to modify code written by others, try to start fixing bugs or writing features for an open source project. In either case you should immediately see how frustrating it is to try to figure out why things in the code base are the way they are, and I think the best solution is not documentation but clear, clean code that self-documents, not with comments but with small focused recipe-like functions. Bob Martin's book
Clean Code[1] is a quick read that makes clear how this can be done effectively. Martin Fowler's book[2] is another obviously good illustration.
The second thing that has really influenced my coding style for the better (making it clearer and easier to understand) is writing a medium-sized program using a strictly functional language like Erlang. This will force you to use global state less, to write functions in such a manner that the function itself includes all the information required to understand it, simply because global state cannot be used and everything on which the function operates must be passed into it explicitly via its parameters.
[1] Clean Code (Robert Martin)
http://amzn.to/2uewcpB
[2] Refactoring (Martin Fowler)
http://amzn.to/2vnD7vx
Currently read and recently read, in no particular order:
Modern C++ Design (Andrei Alexandrescu)
The Screenwriter's Bible (David Trottier)
Clean Code (Robert Cecil Martin)
Il Codice da Vinci (Dan Brown)
The Anatomy of Story (John Truby)
A Random Walk Down Wall Street (Burton Malkiel)
The Power of Habit (Charles Duhigg)
No, wouldn't buy it.
The beginning of Part 1 looks more like a beginner programming book than a C++ book. They're important topics, but none of them are specific to C++, and they're not the reason I'm buying a C++ book.
The rest of Part 1 looks like a rehash of "Code Complete" and "Clean Code." There are already good books on those subjects, and I'm not seeing what this one adds. Might be interesting to the same people who don't know about SCM and compiler warnings, but I'm not in that demographic, and even they are probably better off in the long run going with other books.
Part 2 looks interesting, but not enough to buy the first half of the book along with it. There are other books on writing reliable multi-process/multi-threaded code (both in general and in C++), and my impression is they would go into more depth than a book that tries to be as broad as this one.
I should point out I was already predisposed to say "no" because my preference is to avoid books that tie themselves to a specific language unless I'm learning the language or the particular language has an unusual advantage for a particular thing (such as Erlang for reliable multi-processing). Unfortunately neither of those apply here, so I'd prefer the more general books on these topics.
I read Clean Code in 2010 and trying out and applying some of the principles really helped to make my code more maintainable.
Now over 10 years later I have come to realize that you cannot set up too many rules on how to structure and write code. It is like forcing all authors to apply the same writing style or all artists to draw their paintings with the exact same technique.
With that analogy in mind, I think that one of the biggest contributors to messy code is having a lot of developers, all with different preferences, working in the same code base. Just imagine having 100 different writers trying to write a book, this is the challenge we are trying to address.
This is true, it's essentially a summary of some of
Clean Code by Robert Martin. Principles applicable all over the place.
However to turn things a bit more constructive, let me know what languages you see as less of a mess if you have the time. It doesn't matter whether we agree and I'm not looking for a fight, just your opinion and reasoning. I might well agree.
I got books like sheiks got oil. I'm swimming in them. I try to read a little from at least four books every day. (You'll have to look up these links yourself)
-----------------------------------------------------------
On my Kindle:
Anna Karenina, Tolstoy; Clean Code, Uncle Bob; Palm WebOS; Antoninus Meditations, Marcus Aurelius, Emperor; Never Eat Alone, and Other Secrets to Success, Ferrazzi
-----------------------------------------------------------
In my stack:
Daniel-X, James Patterson; Born To Run, Christopher McDougall; The Existential Jesus, John Carroll; Fear and Trembling - Repetition, Soren Kierkegaard
-----------------------------------------------------------
On the way in from Amazon:
The Trusted Advisor, Maister; Secrets of Consulting: A Guide to Giving and Getting Advice Successfully, Weinberg; Rain Making: Attract New Clients No Matter What Your Field, Harding
-----------------------------------------------------------
I'm thinking about growing another pair of eyeballs so I can read two books at once. I'll let you know how the genetic engineering goes. (grin)
Here's my rant on Code Complete and
Clean Code:
I find that these two books are in many recommended lists, but I found them entirely unforgettable, entirely too long, and without any "meat."
So much of the advice given is trivial things you'll just figure out in the first few months of coding professionally.
Code for more than a week and you'll figure out how to name classes, how to use variables, how scope works, etc.
The code examples are only in C++, Java, and Visual Basic (ha!). Completely ignoring non-OO and dynamic languages.
Some of the advice is just bad (like prefixing global variables with g_) or incredibly outdated (like, "avoid goto"? Thanks 1968!).
Work on a single software project, or any problem ever, and you'll know that you need to define the problem first. It's not exactly sage advice.
These are cherry-picked examples, but overall Code Complete manages to be too large, go into too specific detail in some areas, while giving vague advice in others.
All books are written in a time and a few become timeless. Software books have an especially short half-life. I think Code Complete was a book Software Engineering needed in 2004, but has since dropped in value.
I will say, that Code Complete does have utility as a way to prop up your monitor for increased ergonomics, which is something you should never ignore.
I have similar issues with Clean Code. One is better off just googling "SOLID Principles" and then just programming using small interfaces more often and use fewer subclasses.
A better alternative is (from above) The Pragmatic Programmer (2019), a good style guide, and/or get your code reviewed by literally anyone.
I haven't read "
Clean Code", but I grokked through a bunch of Uncle Bob's stuff in creating Obvious Architecture and I have to say that I think that many programmers don't/won't get what Uncle Bob is going on about because many programmers want to take the parts they agree with and throw away the rest in the name of "pragmatism".
In reality, Uncle Bob's stuff is actually better when taken holistically and when applied together, but it's hard to do and when taken to their logical conclusion, it is so outside the norms of OOP, that people freak out about it not being "proper OOP" as they were taught in university and in mainstream things.
If you're like me, nothing. I need to sit down and find ways to break something to understand how it works.
What I do find useful is listening to books on practice or management. Something like The Pragmatic Programmer, The Practice of Programming, and Clean Code. These are high on substance but (relatively) low on examples, so I feel I can still benefit from their insights without having to be in front of a screen.
Those are all goals that with a little work should be surmountable.
When CS majors or programmers estimate how fast/efficient code is they generally are intuitively applying big 'O' notation or some similar concept. This can be gained from an intro level algorithms class. Or you could look up and read about the topic.
The classical coding interview questions mostly stem from an intro algorithms and data structures class. Or you could get a book on interview prep and work through a couple a day.
Finally, the coding style issue usually is ancillary knowledge and not found (or at least not done well) in typical CS curricular. I would suggest the book "Clean Code" by Robert Martin. It goes through code smells, commenting, general style, and is well written.
So overall, you could look at Algorithms and Data Structures MOOC's. Also read a book on CS interview prep and writing maintainable code. Hope this helps a little. Good Luck!
demand more money now, concentrate on learning to work with people, but
do not give up on code quality.
Not entirely, anyway. You can't turn the whole app into a good one in any reasonable time, but when you fix a bug, take time to apply the boy scout rule ( http://www.informit.com/articles/article.aspx?p=1235624&... ) Don't put that down as a separate task that your management can approve or deny, it's part of doing the job of coding properly. That way, at least the buggy parts of the app get better.
You should not be focused only on your career when making coding and tech decisions, but look at it this way: in a year's time, you're in an interview for a job you really want. What are you going to say "I can read and maintain shitty code" or "I can make shitty code better"?
Also consider: documenting your app's architecture (or lack of it) and conventions (or lack of them).
Also consider: reading up on architecture, testing, refactoring and code quality. If nothing else, these will help you get your next, better job. Off the top of my head, try "Domain Driven Design" by Eric Evans, "Growing object-oriented software guided by tests", "Refactoring" By Martin Fowler, and on the last topic "Clean code" by Robert Martin and "Code Complete" by Steve McConnell
Big ball of mud apps (http://www.laputan.org/mud/ ) may be common, but it doesn't have to be that way - you can learn some pitfalls to avoid
While the example in the article isn't great for making the point I actually agree with the main idea.
I understand the arguments for 'Uncle Bobifying' code but I think, as the article says, there's a balance to be struck. It's highly likely the next time I see your code (or my code if I'm coming back to it a month or two later) is when I need to fix a problem with it. While it's useful to have it split up into logically discrete chunks with sensible naming these 2-4 line functions far increase the mental load of the code.
Given I'm debugging the code because there is presumably a problem with it I can't trust these sensibly named functions to do what they say, I need to check their internals to reason about changes in application state. Though well named functions at least help the maintenance programmer reason about the why they're equally liable to code rot as the comments they replace.
As in all things there's a balance to be struck but I'd rather see a 20-30 line method than jump between 5 files because someone has read Clean Code recently.
Read:
The Pragmatic Programmer by Andrew Hunt & David Thomas
Code Complete 2 by Steve McConnell
Clean Code by James O. Coplien
Test Driven Development by Kent Beck (save this for last)
These books will teach you how to think and approach coding in a way that will make Object Oriented programming simpler to comprehend.
I can't suggest a book that explains basic OOP principals, hopefully some other much smarter person here can. I learned basic OOP through practice and through my education/class - but to be honest the basics are dead simple. It's only when you start getting into the very abstract that OOP starts to get really complicated and that's where the above books will help you.
I would get 5 books on the topic. Bring them home, try them all, and you're bound to find one that you like and can work your way through.
One I'd recommend is "Eloquent Javascript". It may be a tiny bit out of date now (I read it over 5 years ago maybe, and Javascript has improved a lot since then), but it's a solid book.
Other books you might like: Pragmatic Programmer, Pattern on the Stone, Clean Code, Mastering Regular Expressions.
>
Now I'm a little worried that if my situation doesn't change, my career would suffer. I've started to watch a few videos online about design. But I'm not sure if they're going to really help as they usually talk about very basics which doesn't help in real world coding.Check the PRs and read the existing code from others inside the company. Presumably those meet the company's standards, and will give you hints how to structure yours.
Read a couple of industry standard books like Clean Code and Code Complete too.
Google for blogs written by Google's Site Reliability Engineers - SREs. The Visible Ops Handbook is where devops as a movement, seems to have begun. But Devops is really about taking things like ITIL standards more seriously. It is unfortunate that too many people aim for buzzword compliance with any published standard, without looking for the essential meaning of the standard and adapting that to their own environment. Therefore a lot of stuff on the net about ITIL is crap, but the essential principles and practices that ITIL documents, are necessary for any serious Internet service company. And part of that is that software developers have to be involved in engineering how their apps are deployed and operated and CHANGED. No more silos between ops/sysadmins and developers. In the ideal end game of devops, there would be no more ops/sysadmin roles, just software developers, some of whom specialize in maintaining/improving site reliability. If you are in ops then you need to learn professional software development practices (Bob Martin's book Clean Code comes to mind) and if you are a developer, it means that you need to learn more about managed processes (human processes) and about the architecture of the things that run your code. You have heard of cores, but what about L1 cache and false sharing? How much time does your app spend waiting on locks? Why don't you know the answer to that last question? How do you measure/monitor your apps? If you answered Nagios, go back to school. Uptime is irrelevant, it is application health that matters, resource utilization and so on. Send data to Graphite to build up a historical view of your app behavior. If there is too much data being generated then use statsd or metricsd to only send a random sample of the data, because "too much" is a code for "a random sample would be statistically significant therefore I don't need all the data points".
These are a bit specific. I feel as though they might, in fact, have been the last 4 books the author has happened to read.
Anyhow, I expect we'll get the usual round up here. Code Complete, of course; plus a smattering of rebels who think it was boring or irrelevant. The Pragmatic Programmer will receive universal praise, especially from those who didn't take the time to read Code Complete from cover to cover.
Some of the debate will be about whether Code Complete is "better" than Clean Code or not. A silly argument, they are complementary (though, really, is this even a debate worth having? Code Complete is clearly the better book).
Let's see, what else?
Structure and Interpretation of Computer Programs will get mentioned, which will spawn a fertile subthread arguing about whether computer science books really belong on a list for developers. That subthread will debate the merits of Introduction to Algorithms vs everything else, and someone will mention a lisp book that changed their life. Probably Paradigms of Artificial Programming or On Lisp.
The Gang of Four will get nodded at. Like the Bible, Homer, or Peopleware it will be the book everyone says they've read but which almost nobody has actually read.
The C Programming Language will be mentioned. These days that means Zed Shaw will be named and hilarity will ensue.
Myself? I'd definitely have Code Complete (I still have my first edition), perhaps A Discipline for Software Engineering and Software Estimation: Demystifying the Black Art. I've found pretty much everything from Dorset House to be worth my time, so to PeopleWare I'd add The Deadline and Adrenalin Junkies and Template Zombies.
What we don't do in this industry, however, is read more widely. Get out of your rut. Read about history, read some classics, read deeply in another field you pursue as your hobby. Everything illuminates everything. Get out there, see the intellectual sights (for which, get a copy of Dawn to Decadence by Jacques Barzun for a guided tour). You'll be a better developer and a better person for the trouble.
I am currently reading Clean Code and there are so many useful hints in there, comments being one of the thi gs that stuck in my head.
Talking about syntax highlighting, I edited my editor to treat @Todo and similar comment additions in the same way as errors: they do not belong thete and should be fixed as soon as possible. Marking them ass errors led to several small fixes.
After reading this article I might try the same with regular comments.
Well, reading between the lines, PG thinks very little of OO.
Uncle Bob's book Clean Code demonstrates very small methods in C#, and it does go in the direction of looking for language constructs. It is just harder to get there in a non-lisp language.
Regarding OO in general, I am a former proponent of OO--in fact taught (delivered might be a more accurate description) the Rational Unified approach several times, brought OO thinking to several business units. Reading PG and getting heavily into Lisp took me away from that.
I think we disagree slightly on "whole program complexity" and the increasing complexity of shifting it around.
tmalyonJan 26, 2018
Kent Beck's 4 rules of simple design is great. You can find the rules online.
Some great books are Clean Code, Pragmatic Programmer, Working Effectively with Legacy Code
sidcoolonMay 25, 2021
sidcoolonJan 9, 2019
Clean Code by Robert Martin
Beautiful Code by Andy Ormen, Greg Wilson
Refactoring 2 by Martin Fowler
user123456780onJuly 20, 2021
Working With Legacy Code - Michael Feathers
custardbeansonMay 25, 2021
I don't agree with everything.
I think it would be a mistake to take it on it's every recommendation.
vonseelonDec 31, 2017
grammarnazzzionMay 25, 2021
timclarkonJune 5, 2017
Implementing Domain Driven Design by Vaughn Vernon
Clean Code by Robert Martin
I think you will find some code in all of the books but the ideas are applicable almost everywhere.
louhikeonNov 23, 2016
MithrilTuxedoonJuly 25, 2017
This helped me break my analysis paralysis when it came to figuring out how to organize my code.
bmayonDec 19, 2018
Clean Code is not a soft-skill book.
lgunschonMay 16, 2014
bytematiconMay 23, 2018
mncaudillonJan 13, 2014
DanielRibeiroonAug 1, 2010
davidjnelsononJan 19, 2013
tmalyonSep 19, 2018
Picking a side project is a great way to learn and grow.
If you learn from books, I would recommend Test Driven Development by Kent Beck, Clean Code by Robert Martin, The Philosophy of Software Development
kevinherrononNov 3, 2010
Working my way through the "Sprawl trilogy" :)
Also, Clean Code: A Handbook of Agile Software Craftsmanship by Robert C. Martin.
yeezulonNov 6, 2014
It deals specifically with the mistakes you've mentioned in your post, such as hardcoding and naming functions.
Great easy read.
Cheers
dave_sidonOct 4, 2018
fdwonFeb 11, 2018
bguthrieonFeb 14, 2012
http://www.amazon.com/Clean-Code-Handbook-Software-Craftsman...
vollmondonJune 22, 2015
geoelkhonJune 25, 2021
Did not finish Clean Code yet but enjoying it so far too.
vollmondonJune 22, 2015
raifliponFeb 22, 2019
Clean Code: https://www.amazon.com/Clean-Code-Handbook-Software-Craftsma...
Clean Architecture: https://www.amazon.com/Clean-Architecture-Craftsmans-Softwar...
Domain Driven Design: https://www.amazon.com/Domain-Driven-Design-Tackling-Complex...
EgidiusonJan 8, 2017
There should be some kind of ESLint preset that enforces these principles where possible?
tmalyonNov 22, 2016
tnoletonSep 18, 2019
Methods and functions should be around 5 lines.
Doesn’t always work but is great to aim for.
yeraydariasonNov 23, 2016
bwh2onMar 31, 2021
urxvtcdonApr 7, 2020
tmalyonJune 28, 2016
I did find some value in Code Complete, but it is a little too long for my tastes. The naming and abstract data structure sections were probably my favorite parts of that book.
chinhodadoonAug 11, 2017
This is why books like Clean Code can be harmful. It can be extremely dogmatic if blindly followed, which is very common unfortunately.
kissgyorgyonDec 10, 2019
thundergolferonJuly 2, 2020
joaopbnogueiraonMay 25, 2021
This book was written to make developers think and consider their choices, not a script for good code.
IggleSniggleonDec 22, 2020
tmalyonSep 22, 2020
Take a look at the Clean Code book. The chapters on functions and naming are some of the best.
kasey_junkonNov 20, 2013
Designing object-oriented C++ applications using the Booch method
and really liked:
Agile Software Development: Principles, Patterns and Practices.
I didn't think Clean Code was worth it though.
avelisonDec 30, 2013
asdffdsaonMay 13, 2019
drakonkaonSep 15, 2016
dreistdreistonMay 14, 2018
- Clean Code
- Code Complete 2
- The Pragmatic Programmer
- Professional PHP
- Effective Java
- Domain Driven Design Distilled
coverbandonNov 22, 2016
runesoerensenonAug 18, 2016
thedualityonJuly 27, 2018
thezoctoronFeb 28, 2019
seanmraffertyonApr 7, 2020
Code Complete: A Practical Handbook of Software Construction, Second Edition
Clean Code: A Handbook of Agile Software Craftsmanship
tmalyonSep 16, 2018
For technical skills, I recommend reading Clean Code, Test Driven Development, and The Philosophy of Software Design.
p0nceonMay 25, 2021
laurent92onJune 29, 2021
simiasonMay 25, 2021
DextroonFeb 22, 2019
ljkonApr 15, 2015
lgunschonNov 12, 2018
sudshekharonDec 27, 2016
Be polite and friendly (lots of rejections happen because of bad attitude).
Would recommend reading Clean Code. Might help you improve the quality of the programs you write during interviews.
Jerry2onFeb 22, 2019
[0] https://www.oreilly.com/library/view/clean-code/978013608323...
derangedHorseonDec 18, 2019
macandoonApr 7, 2021
I have a feeling the OP is looking for a book about software development in a broad sense.
skocznymrocznyonApr 3, 2020
awjronMay 18, 2017
Looking back 24 years, I'd also add, to be more involved in the local hacking community and participate in hackathons.
Anybody can code, but to make a difference, you need to network ;)
lmarcosonMar 1, 2021
Software engineering has more to do with people than with software. Have you checked Peopleware? Also, perhaps The Phoenix Project could help as well.
lvillanionDec 27, 2011
- "Physics for Future Presidents" by Richard Muller
Not really a book but I found the "MIT Guide to Lock Picking" an interesting read.
DanielBMarkhamonMar 26, 2010
Having said that, remember the idea is to stick with a theme, so if you choose good coding, do "Clean Code" by Uncle Bob a few other books along the same lines.
lobstrosity420onMay 25, 2021
alexchamberlainonDec 17, 2012
adamrichardsononDec 1, 2010
http://www.amazon.com/Clean-Code-Handbook-Software-Craftsman...
blacktriangleonMar 29, 2021
So yeah, feel free to disagree with Uncle Bob, but in no way is he "under-substantiated.
SimmoonDec 18, 2019
High Output Management Grove, Andrew S.
7 Habits Of Highly Effective People Covey, Stephen R
Clean Code: A Handbook of Agile Software Craftsmanship,(Robert C. Martin)
Clean Architecture: A Craftsman's Guide to Software Structure and Design (Robert C. Martin Series)
Building Evolutionary Architectures: Support Constant Change by Neal Ford, Rebecca Parsons, Patrick Kua
If you have read any of them and you would like to share your thoughts, I will be truly happy to listen!:)
Happy reading
amriksohataonSep 16, 2018
strict9onMay 25, 2021
Fixed the typo, thanks.
retrogradeorbitonMay 6, 2013
Best resources and books? There are just so many good books. Last one I enjoyed was The Pragmatic Programmer. Next I'm going to try reading Clean Code.
Keep learning. Keep reading. Keep writing.
macandoonMar 31, 2021
ebiesteronJuly 7, 2014
Then I'd move on to Domain Driven Design and probably Refactoring and Growing Object Oriented Software, Guided By Tests.
Those four will give a good start to what enterprise/OO people are expecting in design.
busterarmonMay 9, 2018
1) Clean Code
2) The Phoenix Project
3) UNIX and Linux System Administration Handbook
I'm sure #2 will be something folks want to fight over shrug. If you want to sidestep years of headache it's a must-read though.
aurahamonMay 25, 2021
[0] https://pragprog.com/titles/tpp20/the-pragmatic-programmer-2...
lgunschonMar 18, 2016
Kent Beck in his book doesn't recommend top-down, or bottom-up, but rather from known-to-unknown. Start with what you know, and work toward what you don't know.
Edit: The books I refer to are Test Driven Development: By Example - Kent Beck, and Clean Code - Robert Martin
vital101onApr 20, 2010
drdebugonAug 31, 2020
TeeDubonDec 22, 2012
Feathers (the author) methodologically chose to copy / inspire some of his examples from code he's worked with as a mentor / developer (some of it from his time @ Thought Works w/ Beck, et al.)
The book is similar to Fowler's Refactoring in that it provides some core thought processes / ideology and then a long list of heuristics and techniques for revising/updating legacy code. (I find his definition of "legacy code" as any software without automated testing to be challenging and insightful, especially since it indicts most code written ever. ;)
If you get the chance, you could also consider reading "Clean Code", it doesn't have /as much/ "real world" source but is still excellent.
DanielBMarkhamonSep 4, 2009
What I want to know is how in the heck do you get to call yourself "Uncle Bob"? What? Is there like an agile family, with uncles and nephews and stuff? If so, I want to be Cousin Dan
lboassoonAug 30, 2018
[0] https://www.amazon.com/Philosophy-Software-Design-John-Ouste...
amriksohataonDec 30, 2016
dep_bonOct 6, 2017
There's not a lot in Clean Code that I wouldn't recommend to most programmers.
RoyalSlothonJune 28, 2020
I also found myself agreeing with everything written in this blog post. For the record I have read his famous Clean Code, Clean Coder and Clean Architecture and I don't find them all that meaningful.
memracomonSep 18, 2013
Yes, it is only 3 paragraphs and a title, but if you want it in book form you can print it out and put it between some covers. The important thing is to read those 3 paragraphs carefully and to think about them. Avoid getting caught up on the bandwagon of some management methodology that claims to be Agile, because it probably isn't.
And read Clean Code by Robert Martin, one of the writers of the Agile Manifesto. One of the things encouraged by Agile is TDD, that is to say, a cycle of coding that starts by writing a failing test, then writing code to pass the test and then refactoring code to be better according to principles like DRY and YAGNI.
If you work in this Red-Green-Refactor cycle, then you will have a tough time when faced with a tangle of spaghetti code written in Java or C++. That's when books like Working Effectively with Legacy Code by Michael Feathers come in handy.
In general, steer clear of books about Agile, and focus on books that teach something real, but happen to fit into the Agile Manifesto philosophy. Talk to some developers that you know are truly Agile developers, not practitioners of a methodology, and ask them for book recommendations.
honkycatonMay 25, 2021
I don't believe in being prescriptive to anyone about how they write their code, because I think people have different preferences and forcing someone to write small functions when they tend to write large functions well is a unique form of torture. Just leave people alone and let them do their job!
I don't think it is the perfect solution, but a lot of people assert "we can't do better, no point in trying, just write whatever you feel like" and I think that is a degenerate attitude. We CAN find better ways to construct and organize our code, and I don't think we should stop trying because people don't want to update their pull requests.
otrasonNov 4, 2018
Clean Code: A Handbook of Agile Software Craftsmanship [0] is a great book on writing and reading code.
Similarly, Clean Architecture: A Craftsman's Guide to Software Structure and Design [1] is, no surprise, a book on organizing and architecting software.
Designing Data-Intensive Applications [2] may be overkill for your situation, but it's a good read to get an idea about how large scale applications function.
The Architecture of Open Source Applications [3] is a fantastic free resource that walks through how many applications are built. As another comment mentioned, reading code and understanding how other programs are built are great ways to build your "how to do things" repertoire.
Finally, I'd also recommend taking some classes. I started as a self-taught developer, but I've since taken classes both in-person and online that have been a tremendous help. There are many available for free online, and if in-person classes work better for you (motivation, support, resources, etc), definitely go that route. They're a fantastic way to grow.
[0]: https://www.amazon.com/Clean-Code-Handbook-Software-Craftsma...
[1]: https://www.amazon.com/Clean-Architecture-Craftsmans-Softwar...
[2]: https://www.amazon.com/Designing-Data-Intensive-Applications...
[3]: http://aosabook.org/en/index.html
cureyourheadonSep 16, 2016
I'm considering the perspective that think clean code is this ideal that can be misused by reviewers to blackball otherwise good code for arbitrary personal reasons.
I know the book Clean Code and I like the ideas in it. I just haven't seen any production examples and I'm considering the idea that talking about clean code is a hand waving way to criticize others contributions without substance.
gvjddbnvdrbvonJan 12, 2020
The book Clean Code specifically addresses this area and his final conclusion is compatible with the concepts of clean code.
I think devs should read Clean Code multiple times during their professional life.
amriksohataonOct 3, 2018
cocoa19onJuly 25, 2017
I've read it and I thought it has some good ideas. It's the #3 most discussed book on StackOverflow. However, I've been downvoted on HN for recommending something the book talks about (comments are usually misused)
Maybe I'm missing something more experienced developers know.
douglaswlanceonDec 16, 2019
The best books I've ever read:
broahmedonJan 10, 2019
For other books, this page is also a good start: https://hackernewsbooks.com/top-books-on-hacker-news
mortivoreonDec 16, 2019
Children of the Nameless by Brandon Sanderson - Probably one of the few very good magic the gathering books.
Augustus: The Life of Rome's First Emperor by Anthony Everitt - excellent overview of the emperor
King Rat by James Clavell - fictional depiction of being a prisoner in a Japanese camp during WW2.
1493: Uncovering the New World Columbus Created by Charles C. Mann - talks about the natives in the Americas after first contact. Follow up to 1491.
Clean Code: A Handbook of Agile Software Craftsmanship by Robert C. Martin - Good book for people looking to write clearer, more understandable code
The Elric Saga Part 1 by Michael Moorcock - Interesting protagonist.
Currently enjoying and will finish by end of year:
The Starless Sea by Erin Morgenstern - It's about stories so far. If you liked the Night Circus, then you will like this. Great atmosphere.
leaflordonMay 29, 2020
While I do think that Bob goes overboard with his suggestions in Clean Code, I found it as a necessary counterbalance to encourage readable code in my team, where the methods tends to be gigantic blobs. I'm sure there are better books, but it was a good one.
For instance, one suggestion I did like from Clean Code is to separate exception handling from business logic. I don't always practice it, but it really helped in making my work-related code more readable.
krigathonDec 12, 2018
Dare to Lead (interesting and Powerful)
Rising Strong (Sensible)
What the most successful people do before breakfast (helpful in thinking about opportunity costs)
Why we sleep (interesting read)
Exponential organisations (Re-read after 2 years, worth it)
Prisoners of Geography (very interesting view of geopolitics, Putin, et al)
Continuous Delivery (great!)
Clean Code (must read for any serious programmer)
Built to last (picked it back after 1-2 years, cool book)
Site Reliability Engineering (didn't quite finish, but good book)
Building Microservices (fantastic book which puts everything I've done in the past year into so much more perspective)
theflyinghorseonMay 25, 2021
Of course reading Clean Code left me more confused than enlightened due precisely to what he presents as good examples of Code. The author of the article really does hit the nail on the head about Martin's code style - it's borderline unreadable a lot of times.
Who the f. even is Robert Martin?! What has he built? As far as I am able to see he is famous and revered because he is famous and revered.
jupp0ronJune 1, 2016
mortivoreonNov 12, 2019
Children of the Nameless by Brandon Sanderson
Augustus: The Life of Rome's First Emperor by Anthony Everitt
King Rat by James Clavell
1493: Uncovering the New World Columbus Created by Charles C. Mann
Clean Code: A Handbook of Agile Software Craftsmanship by Robert C. Martin
The Elric Saga Part 1 by Michael Moorcock
matijashonFeb 19, 2020
Besides Martin Fowler which was already recommended, I would also recommend the books by Robert C. Martin (Uncle Bob), and his "Clean" series - there are books "Clean Code", "Clean Architecture" - all of them are really good and useful and will give you a solid foundation to build on.
Other than that, the best thing you can do is to get practice & ideally surround yourself with more experienced developers. Either get an internship in a company building something more complex, or participate in e.g. Google Summer of Code.
Doing fun side projects is also a great way - you learn a lot and also have something to show & write about - win-win!
alisonatworkonMar 2, 2020
I only have one cert - the Sun Certified Java Programmer, from back in the day when Sun still existed - and i can say it encouraged me to dive deeper into the quirks of the language. For sure, reading Effective Java gets you more bang for the buck in becoming a great Java developer, and stuff like Clean Code probably helps more with learning how to build maintainable apps, but i still feel like the SCJP was worth my time to do.
The thing i found about doing the SCJP is that it increased my curiosity around programming languages in general. Those contrived "gotcha" questions on visibility, inheritance etc made me think more deeply about how to design code in a readable and safe way - not just in Java but in other languages too.
vargavince91onOct 8, 2016
Would help if you shared the end goal. Get hired anywhere? Get hired by Top 4 Tech Company or Hot Startup of the Year? Start a business? Don't get bored? How long is he going to be incarcerated?
I would greatly appreciate if you shared your experience.
JTrilogyonNov 27, 2016
My current reading list:
* Code Complete: A Practical Handbook of Software Construction - Steve McConnell
* Agile Software Development - Robert C. Martin
Upcoming reading list:
* Node.js Design Patterns - Mario Casciaro
* The Pragmatic Programmer: From Journeyman to Master - Andrew Hunt
* Clean Code - Robert C. Martin
* Refactoring: Improving the Design of Existing Code - Martin Fowler
And maybe Working Effectively with Legacy Code by Michael Feathers.
If anyone has any comments or other suggested readings I'd love to hear them!
rluharonMay 29, 2013
Robert ("Uncle Bob") Martin's book has been really useful for us. We have been going through the book section by section and comparing the ideas in "Clean Code" to our implementations. It has been a most effective way of getting the team up to speed.
I would recommend anyone who is getting started on their first software engineering job to go through the book. It is excellent study material for an inexperienced team.
diegoloonOct 11, 2020
'Avoid mental mapping: In general programmers are pretty smart people. Smart people sometimes like to show off their smarts by demonstrating their mental juggling abilities. After all, if you can reliably remember that r is the lower-cased version of the url with the host and scheme removed, then you must clearly be very smart.'
jackbaueronMay 11, 2014
Although I detest comments, making them stand out more and consequently wanting (hopefully) to write better code, is a plus. There will be some cases for comments, and it should be few and far between, and only super necessary (read Clean Code for contextual examples).
chasingthewindonSep 6, 2019
1) You're motivated to help
2) The junior engineer is motivated to improve
I don't think it matters what techniques you use if these two things are in place. If they're not in place then it is very likely not going to pay off regardless of how you approach the mechanics.
Code reviews are critical.
Pair programming can be a valuable technique.
Going over concepts and best practices can help.
Creating a plan for the junior engineer to study the craft. Books like Clean Code can be great at starting discussions.
Good luck!
cellularmitosisonNov 6, 2014
ragatskynetonOct 28, 2013
As others stated it is needed to start a project in a way that you care about the quality. Even when there have not been a single line written. Also being agile also means that you refactor and redesign from time to time when it is needed.
I always check my code after implementing a functionality. If it is needed, I refactor my code. Also there are numerous tools to check code quality (e.g. Sonar). A very good approach is to have code reviews as well if you can.
There is a very nice book in this topic which the others have not mentioned, but if you are interested I advise to read it: Clean Code by Robert C. Martin.
grannyg00seonJan 31, 2014
Relevant quote:
"The ideal number of arguments for a function is zero (niladic). Next comes one (monadic), followed closely by two (dyadic). Three arguments (triadic) should be avoided where possible. More than three (polyadic) requires very special justification—and then shouldn’t be used anyway."
tmalyonMay 6, 2019
When I hire a new developer, I always have them read TDD and Clean Code. Even if they don’t get it right away, I aim to get them to pause and think about it.
Some quick software that was written in haste could be running over a decade. And they might be stuck maintaining it
kevinSuttleonOct 28, 2014
URL Design is key. I often refer to the naming chapter of Uncle Bob's Clean Code book for this. This also helps with consistency and predictability, which in turn, makes writing docs easier.
I've got an API Design Readlist, which I've added this thread to. http://readlists.com/6c5c6009/
joshkaonAug 18, 2016
The examples you provided (with some context gleaned from your other comments) look like they're probably too long and tack on unnecessary domain specific detail (e.g. jsonStates).
Both variables in your example would likely be better off describing the use of the variable rather than the contents. E.g. use ageInYears rather than yearsAliveInt. Taking it to your example, perhaps something along the lines of convertedDocument would do, this is significantly shorter than your example, but perhaps conveys enough info for your ongoing usage.
This is covered to in Clean Code [1]. "The name of a variable, function, or class, should answer all the big questions. It should tell you why it exists, what it does, and how it is used." The notes on the naming chapter at [2] are quite good as well (as noted elsewhere on this thread by @runesoerensen)
I like to follow the principle in naming variables that if I could read the code to a non-technical user verbatim and have them understand the code, it is "good code". I.e. does reading the code out loud as a sentence make sense, or do the verbs and nouns I've chosen act as a barrier to understanding.
EDIT:
Ward Cunningham said that last part better:
“You know you are working on clean code when each routine you read turns out to be pretty much what you expected. You can call it beautiful code when the code also makes it look like the language was made for the problem.”
[1] Martin, Robert C. (2008-08-01). Clean Code: A Handbook of Agile Software Craftsmanship (p. 18). Pearson Education. Kindle Edition. https://www.amazon.com/Clean-Code-Handbook-Software-Craftsma...
[2] http://www.itiseezee.com/?p=83
diego_moitaonDec 23, 2019
Code Complete is a problematic book. It has some good ideas but also has some very bad ones (cone of uncertainty, 10 times productivity in good programmers, etc).
Design Patterns is mostly obsolete. Functional programming techniques made a lot of Object Oriented techniques irrelevant (e.g.: observer pattern vs callbacks with lambdas).
Art of Computer Programming is the book everyone mentions but no one reads. A classic that people actually read is Structure and Interpretation of Computer Programs.
My recommendations: "Code" by Charles Petzold,"Don't make me think" by Steve Krug, Working Effectivelly with Legacy Code, by Robert Feathers, Clean Code by uncle Bob,..
randomsearchonSep 25, 2015
I really don't know the answer, but find it fascinating and can't wait to see what Facebook is doing in 10 years time.
andrewprockonDec 18, 2018
* The Pragmatic Programmer
* Clean Code
* The Clean Coder
* Domain-Driven Design
* Growing Object-Oriented Software, Guided by Tests
All of these books take the simple maxim:
"Be organized, and stay organized"
and spend thousands of pages expanding on that.
PJDKonJune 15, 2018
Read the "classics" - Code Complete, Pragmatic Programmer, Clean Code etc. Google "best books about programming" and you'll find plenty.
When you're reading think about the why. You're job is dealing in complexity and there is no one true way. Understand as many of the different ways as possible.
If you think an idea is weak, try and figure out a question that exposes the weakness (how does this handle a date before 1970?). Expect that sometimes this question will reveal the idea isn't as weak as you initially expected.
Remember you only need to solve the problem that's in front of you. If that problem doesn't seem easy try to break it up into smaller problems.
Complicated solutions are often bad solutions.
Complicated solutions can be good solutions.
Write your code for people to understand.
Advice on good writing is often very applicable to code... See Orwell(1), particularly "Break any of these rules sooner than say anything outright barbarous"
1.https://www.writingclasses.com/toolbox/tips-masters/george-o...
framebitonFeb 14, 2018
The suggested reading for that course is a book that blew my mind when I first saw it as an undergrad: Clean Code by Robert Cecil Martin. I believe the examples are all Java, but the lessons are applicable to any language. Stuff like naming your variables more carefully than you name your children.
https://www.amazon.com/Clean-Code-Handbook-Software-Craftsma...
roryokaneonJune 8, 2011
[1] http://www.amazon.com/Clean-Code-Handbook-Software-Craftsman...
JtsummersonMay 25, 2021
CodeSheikhonJan 17, 2019
- Clean Code (by "Uncle Bob")) [https://www.amazon.com/Clean-Code-Handbook-Software-Craftsma...]
- Design Patterns (by "Gang of 4") [https://www.amazon.com/Design-Patterns-Elements-Reusable-Obj...]
- Introduction to Algorithms (by "CLRS") [https://www.amazon.com/Introduction-Algorithms-3rd-MIT-Press...]
FrancescoRizzionAug 29, 2012
To put this in context: I keep it next to "Agile Software Development" (by the same Uncle Bob), "Working Effectively with Legacy Code" (by M. Feathers), and "Refactoring" (by M. Fowler).
HTH (no, I have no direct or indirect benefit from 'advertising' these books and their authors)
majikandyonDec 29, 2018
It is so frustrating to hear when someone thinks commenting more and adding humour is somehow cleaning up the code. But to then hear that they are teaching this to juniors just hurts so much.
Simpler advice to juniors would be to read Clean Code by Robert C Martin, apply some of those techniques and then politely ignore “more experienced” developers who think writing humourous essays as code comments is a good thing.
I’ve even heard phrases banded around like “the more comments the better” - I mean seriously WTF.
I like the analogy of...
When in an unfamiliar city, having no map at all is much better than a map that you have no idea whether you can trust or not. Code comments are absolutely that untrustworthy map, doesn’t matter how many code reviews or convoluted PR process takes place, you still need to read the code to know the truth so more effort making the code communicate is the key to maintainable code. Simple things like good variable names and grouping behaviour into functions at the same level of abstraction can completely negate the need for comments.
Comments have their place, but should be the exception not the norm.
barumionNov 5, 2020
In your opinion, why do you feel any of those points you made are relevant or have any substance? I mean, the importance of Clean Code is to improve your output by following a few guidelines, not be pedantic and use the book as bible to bash others in bike shedding discussions.
misja111onAug 31, 2020
The other reason is that many FP users are too enthusiastic about creating abstractions.
This is of course something that FP is exceptionally well suited for. An api that was written to simply process a list of Orders into a Report might be abstracted into a fold on some monad, which at first seems a great idea.
But if you're not careful, readability suffers a lot. It's much easier to get to know an application when its code deals with business objects that you already understand well, than to read hundreds of lines of code that deal only with abstractions.
Maybe there should be a new edition of Clean Code written specifically for FP, to address this anti pattern.
By the way this problem is not unique for FP, OOP suffered the same problem in the past. But the OOP community learned from its mistakes and now most developers know to 'prefer composition over inheritance', for instance.
steveklabnikonNov 27, 2010
* Design Patterns: Elements of Reusable Object-Oriented Software
* Refactoring: Improving the Design of Existing Code
* Clean Code: A Handbook of Agile Software Craftsmanship
* Code Complete: A Practical Handbook of Software Construction
And some others:
* Working Effectively with Legacy Code
* Domain-Driven Design: Tackling Complexity in the Heart of Software
mabboonMay 25, 2021
Do I force myself to follow every single crazy rule in Clean Code? Heck no. Some of them I don't agree with. But do I find myself to be a better coder because of what I learned from Bob Martin? Heck yes. Most of the points he makes are insightful and I apply them daily in my job.
Being a professional means learning from many sources and knowing that there's something to learn from each of them- and some things to ignore from each of them. It means trying the things the book recommends, and judging the results yourself.
So I'm going to keep recommending Clean Code to new developers, in the hopes that they can learn the good bits, and learn to ignore the bad bits. Because so far, I haven't found a book with more good bits (from my perspective) and fewer bad bits (from my perspective).
[0]https://en.wikipedia.org/wiki/Don%27t_throw_the_baby_out_wit...
aristofunonMay 25, 2021
Because Clean Code is really a good book once you have enough experience to understand when each idea works and when does not. And why.
And noobs tend to over-engineer, so any book like CC or design patterns give them additional excuse and reason to over engineer and make a mess.
darksaintsonMay 25, 2021
The problem is that Uncle Bob has a delusional cult following (that he deliberately cultivated), which takes everything he says at face value, and are willing to drown out any dissenting voices with a non-stop barrage of bullshit platitudes.
There are plenty of ideas in Clean Code that are great, and there are plenty that are terrible...but the religiosity of adherence to it prevents of from separating the two.
ThrowawayR2onApr 20, 2019
Remember that the people who wrote those books cut their teeth in the pre-web days. It was a much different world back then; there was a huge incentive to get things right the first time because patches were difficult to get to users.
Jobs like the kind you describe exist but are uncommon; usually they can be found in businesses that build tech products and platforms (software or hardware) or in the FAANG companies. Given your background, I'd suggest looking for a job at one of the games middleware companies if you haven't soured on the idea of being a developer entirely.
cfedukeonJune 22, 2015
Java Concurrency in Practice (2006) is older but relevant and clearly describes concurrency on the JVM. A must read for any Java, Scala, Clojure, etc. software engineer; well-written, enjoyable, concise.
Practical Object Oriented Design in Ruby by Sandi Metz is a fun read packed with good principles for working in Ruby that are applicable in general to object oriented programming.
Smalltalk Best Practice Patterns by Kent Beck is worth a read because the general principles are applicable to any OOP language.
Clean Code by Robert Martin is excellent but a time commitment. (If you had to pick between SICP and Clean Code because time is at a premium I'd err on the side of Clean Code for practicality. Writing maintainable code is paramount.)
The Joy of Clojure (Fogus/Houser) is excellent and mentally digestable even if you have no Lisp or Clojure background.
donwonJune 24, 2020
Period.
Instead, only build what you need to solve the problems you have in-hand, but do so in such a way that your software and your systems are as easy to change as possible in the future.
Because you very, very rarely know what your future use-cases really are. Markets change over time, and your understanding of the market will also shift, both because some of your assumptions were wrong, and because you can never really have a total understanding of such a complex phenomenon.
Your business needs will change as well; your top priority from 2019 is likely very different than it is today.
That is why you build to embrace change, rather than barricade against it.
As to how, I'd start with Sandi Metz's 99 Bottles of OOP: https://www.sandimetz.com/99bottles
Learning to write readable code is also pretty important; Clean Code is a good starting point (https://amzn.to/3168z3A), but I'd be keen to know of any shorter books that cover the same materials.
Growing Object-Oriented Software Guided By Tests (GOOSGT) is a good read as well: https://amzn.to/3du1sEL
vxpzxonJune 2, 2019
Also, you don't necessarily need to cover something completely in order to get started. And these will be useful mostly if your work is in some way part of a software product instead of being some "offline" analysis, model build or forecast. Just learning to use version control, to collaborate with other developers and to run tests goes a long way.
sonecaonJan 9, 2018
If you passed that stage, I recommend the book The Pragmatic Programmer as a very good book on how to become a good software developer. The book Clean Code is a good starting point too.
Other than it depends on your circumstances. A good heuristic (particularly in frontend world) is to study the language, not frameworks.
ivanmaederonJuly 18, 2014
But I've also heard about math PhDs write the sloppiest code code imaginable: functions 1000+ lines long, copying and pasting functions to add a parameter... (in production code for a software company, not a research project).
So like you said, math helps but I'd like to extend that thought and say that you can make bigger gains elsewhere. For example, if you're a sloppy coder and don't know math, go out and get a book like "Code Complete," "The Pragmatic Programmer" or "Clean Code" first.
davnicwilonOct 20, 2015
For me this was one of the greatest lessons of Clean Code by Bob Martin, in my opinion a wonderful book which completely changed and dramatically improved the way I write code. By improvement I mean simply the ease with which I can understand and modify my own code months after writing it/ seeing it last.
There's a slight contradiction here with another great lesson of that book though which is short code (by lines) > longer code simply because it's easier to consume in a single glance. There's certainly a delicate balance at play here.
It's a great thing to break down a complex process into steps, naming those steps as you go, and storing things in variables achieves that. However sometimes a better tool, and again another frequent suggestion in Clean Code (really, all credit to Bob Martin for all these ideas) is to instead break the steps into clearly-named functions, if this is possible. Chaining or nesting a series of function calls, depending on the language, can be more readable still than the variables approach and at the same time more concise.
Another great tool for the belt and one of the reasons I have come to always prefer programming in a functional style vs a more stateful, OO style, where I can (even within pretty OO languages such as Java - though the lambdas in 8 have greatly improved the ease with which this can be done).
JamesBarneyonFeb 22, 2019
But if you recommend and say it's similar to Code Complete I'll give it a shot. What I liked most about Code Complete is he always talks about trade offs with a clear goal in mind. For instance if function sizes are too small hidden pre-conditions or side effects can cause a bug. But if functions are too large they are hard to follow and it's difficult to isolate side effects.
rcavezzaonApr 1, 2019
― Robert C. Martin, Clean Code: A Handbook of Agile Software Craftsmanship
https://www.goodreads.com/quotes/835238-indeed-the-ratio-of-...
mokslyonMay 13, 2021
Why does the domain-driven-design chapter come after you’ve tied the reader into GCP? I can’t think of a single enterprise business domain where that would make sense from a European GDPR driven perspective.
Why do you think you can cover that many topics in a single book? I mean, part of the reason Clean Code is well liked is because it covers one topic in depth, rather than covering a bunch of different topics without ever giving the reader anything of value on any of them.
Have you considered going the TDD GOAT book route of earning sales?
I’m really sorry that I’m so negative, but your “contents” read like every terrible tech-book I’ve ever opened. Good luck though.
matsemannonDec 16, 2019
For patterns, "Head First" is a bit childish maybe, but the content is fine for someone learning to recognize patterns. "Patterns of Enterprise..." is also good, but more dry. I'd stick with one of those two. And then skip the one by GoF, unless you want to read the "original" for some reason.
"The Pragmatic Programmer" is probably the book that has shaped my work the most.
franciscoponMar 23, 2017
So I feel like some of the concepts taught in the most recommended books such as Clean Code are only tangentially relevant and some times just plain irrelevant. On the other hand, massive books/material written for pure JS are really low quality compared to these classics (except some blog posts, but with these it's difficult to get a round education).
So the most difficult part for me was to find out which concepts were relevant for JS in high quality books and which were not, something that is not easy when you don't know these concepts. Then learn the things not mentioned that are important for a modern JS developer such as NPM, exporting modules, minimization+gzip+tree shaking, etc.
auganovonAug 15, 2017
The Secret War Against the Jews by John Loftus <- Changed the way I think about inner workings of the government. But at the same time, many claims are hard to verify.
The life changing magic of cleaning up by Marie Kondo <- not life changing but decent and a quick, 2-3 day read.
Nassim Taleb books, pretty sure everyone on here read it or plans to so, don't need my description.
Halfway through The Undoing Project by Michael Lewis at the moment, it's pretty good, a joint biography of Kahneman and Tversky (of the "Thinking, Fast and Slow", which I guess is another HN classic).
valbacaonAug 11, 2020
"Unwritten Laws of Engineering" https://www.amazon.com/dp/0791801624
Originally meant for mechanical engineers, it provides specific and general non-technical career advice. It focuses on what we call “soft” skills today. This field puts so much weight into technical prowess that we often think of these “soft” skills as somehow beneath the “hard” skills. Nothing could be further from the truth. If you don’t spend time on learning how to navigate your career, you’ll be as well off as a dragster on the backroads: you’ll get nowhere fast. I only wish I could have read this book sooner; it would’ve saved me a lot of trouble early on.
"Becoming a Technical Leader" https://www.amazon.com/dp/0932633021
Don’t let the title fool you: this is not just for people planning on becoming a “Tech Lead.” It’s for anyone in the tech field, period. If you pickup this book you must work through the exercises to get the full effect. It will be worth it. It’ll be like having your own therapist, life coach, and mentor, except that it’s just you and a notebook answering very important questions.
"The Pragmatic Programmer" https://www.amazon.com/dp/020161622X
I consider this book 10x better than Clean Code and Code Complete combined! (Though that may just be because I read PragProg first?) As the name suggests, this book provides more tactics advice but also gives great career advice too. The most famous is to “learn a new language each year.” This kind of advice seems a bit much, but over my career I’ve had to write in over a dozen different languages, even though 90% of the code I’ve written has been in just one language, the ability to pickup new languages quickly and easily is a solid skill to have. And that’s just one particular tip from this book.
(These are excerpts from my suggested reads blog post: https://valbaca.com/posts/my-suggested-reads-3cie)
eddie_31003onJuly 7, 2014
1) Clean Code
2) Pragmatic Programmer
3) Patterns for Enterprise Application Architecture
There's some overlap in contents, but I feel they complement each other very well.
notoriousarunonFeb 18, 2021
These books will help you day-to-day with your general programming knowledge...
> Philosophy of Software Design https://www.amazon.com/Philosophy-Software-Design-John-Ouste...
> The Pragmatic Programmer https://www.amazon.com/Pragmatic-Programmer-Journeyman-Maste...
> Clean Code https://www.amazon.com/Clean-Code-Handbook-Software-Craftsma...
> Mythical Man-Month https://www.amazon.com/Mythical-Man-Month-Anniversary-Softwa...
danShumwayonMay 26, 2021
I'm not sure I understand what you're saying, I might be missing your point. The Clean Code book advocates that the ideal function is a single digit number of lines, double digits at the absolute most.
In my mind, the entire process of writing functions that short involves abstracting almost everything your code does. It involves passing data around all over the place and attaching state to objects that get constructed over multiple methods.
How do you create a low-abstraction, bottom-up codebase when every coroutine you need to write is getting turned into dozens of separate functions? I think this is showcased in the code examples that the article author critiques from Clean Code. They're littered with side effects and state mutations. This stuff looks like it would be a nightmare to maintain, because it's over-abstracted.
Martin is writing one-line functions whose entire purpose is to call exactly one other function passing in a boolean. I don't even know if I would call that top-down programming, it feels like critiquing that kind of code or calling it characteristic of their writing style is almost unfair to top-down programmers.
ASTP001onFeb 27, 2020
My team had a discussion about this and some argued that this might alienate programmers who are novices, and might be easier to use "Enlgish" but I think that if the problem space for your software is niche enough then a new team member, or a novice will have to learn terminology either way. In my opinion, programming terminologies are more precise and transferable to other programming jobs and problems in general, so is a more sustainable and relevant way of learning. It might be tough at first, and I agree the attitude of the senior dev would make a huge difference, but as long as the senior dev takes the initial confusion of the novice as a good teaching moment, and explains it patiently and clearly I think it can be more valuable in the long term.
yuraonMar 1, 2021
I agree, that's why I'm asking this question. I think these particular books are mostly helpful to the junior engineer.
But it's hard to believe that from here on out the only thing that's left is to learn how to deal with people. Surely there's more to the software side of software engineering than what TPP and Code Complete have covered. Surely very experienced engineers have written books on software engineering that cover something more than entry-level knowledge. (Clearly, since I haven't found such books yet, there's a chance they haven't been written. But I find that hard to believe, considering the broad audience of software engineers that are interested in that knowledge.)
raisteronMay 2, 2018
1 - Code: The Hidden Language of Computer Hardware and Software by Charles Petzold
2 - Clean Code: A Handbook of Agile Software Craftsmanship by Robert C. Martin
3 - Code Complete: A Practical Handbook of Software Construction by Steve McConnell
4 - Algorithms by Robert Sedgewick & Kevin Wayne
5 - Types and Programming Languages by Benjamin C. Pierce
Best to learn? Highly unlikely.
Interesting? Didn't capture my attention right away.
Good practices? More or less.
Advances the craft? Let's say yes.
llamatabootonNov 6, 2014
datawanderonJan 30, 2014
As someone who once read the Sun Java Style Coding [1] (which at a quick glance, appears to be a super set of the Google style guidelines) standard years ago and found it exciting and very helpful material, I unfortunately did not get such a kick skimming through this. Perhaps it's because after having read Clean Code [2], I feel that there is much missing that can lend itself to better code.
[1] http://www.oracle.com/technetwork/java/javase/documentation/...
[2] http://www.amazon.com/Clean-Code-Handbook-Software-Craftsman...
sadliononMar 4, 2016
What disappointed me was, 3 of the interviewers had no idea about my background and weren't able to extract my strengths. Even though I am a new grad, I have interned for 2 years as an app dev and learned a great deal about design, code quality, testing and etc...
I have read Effective Java, Clean Code, and Head First Design Patterns. I'm reading Java 8 in Action now. I have not memorized them page-to-page and still need more experience to master them, but at least I know some of resources I can go to for more answers. I have participated in code reviews and enjoy them. I can implement LLRBT and many of the algorithms you can expect a new grad to know but I have not invested my time on hacker rank and uva.
I don't know what SV or big tech companies are looking for. I constantly hear interviewers say they want good engineers but fail to capture the essence of a potential good engineer well. What benefit is there in hazing anyone with problems many engineers don't deal with without the tools they use every day, and with an absurd time constraint. Kosaraju didn't come up with SCC in 30 minutes and he had a PHD. Sure I can spend hours studying for whiteboard questions but to what benefit. I am sure anyone of you can come up with a whiteboard problem you can't solve in 30 minutes, but what does that say about you.
k1nsonApr 4, 2018
Computer Principles of Modeling and Simulation - T.G. Lewis/B.J. Smith: I received this book as a gift from one of my favorite professors in college. It was published in 1979, but I find the material still relevant when it comes to introductory concepts of computer simulation.
Big Java Late Objects - Cay Horstmann: Another text from my time at college, specifically from my data structures course. I keep it because I like the way it explains fundamental data structures with well-written Java.
Head First Design Patterns - Eric Freeman/Elizabeth Robson: Another college textbook, and one of my least favorite reads of all time, but I'll be damned if it doesn't explain design patterns well enough for me to keep it around. I refer to it now and then but only when I feel like punishing myself.
Learning PHP, MySQL, JavaScript, & CSS - Robin Nixon: A dangerously outdated introductory web development text that I bought when I was in high school. It was the first programming book I ever purchased and I keep it around because I enjoy remembering what it felt like to explore web development for the first time. I've not referred to it in years, for obvious reasons, but it explained full-stack web development very well and gave me a foundation that I've been able to build on to this day. I remember standing in the tiny Computer Science section at Barnes & Noble where I found it, taking it home and cracking it open, and working through it until I had to make myself go to sleep. It's the first programming book that really hooked me.
ohpeaonJuly 22, 2015
I followed it up by reading Clean Coder for some career advice.
I think the idea of "quick starting" a new job since you have no previous professional experience may set unrealistic expectations and pressure on yourself.
They probably have budgeted on-boarding time for you to figure out some of their stack and lined up some "intro" level work to help you get acclimated.
My advice is be ready to introduce yourself and be honest with your familiarity with the tools they use. Your co-workers probably have awesome things to teach you if you just ask.
VilleSalonenonApr 5, 2011
JtsummersonJune 25, 2021
Martin Kleppmann's Designing Data-Intensive Applications. Based on the frequent praise it receives here, haven't gotten far yet. I have some project ideas (for personal and professional projects) that could benefit from reading through it.
Martin Fowler's 2018 update to Refactoring. I read the original one a long time ago. In context, we have a work lunch & learn series and I'm interested in doing some presentations on the topic of refactoring (why, how, and when in particular) so it seemed appropriate to refresh my memory on some specific terminology from the book as well as to see if it's an appropriate book to recommend to colleagues. My recollection of the first edition is that I'd recommend it to colleagues, but it's been so long I'd rather read it once more before actually recommending it.
I reread Robert C. Martin's Clean Code based on some recent discussion here where it was rather strongly dismissed by a fair number of people. I didn't recall it being bad, my reread confirmed it is not, in fact, bad. Java-heavy, which is now an unpopular style of OOP, but otherwise a very good book. I'd still recommend it to junior colleagues paired with some caveats about avoiding seeing the world in black & white. There is no singular Way of Programming, but learn various ways and find what works for you and your team.
There are some more, but it's almost 5am and I haven't been able to sleep so I don't recall everything that's in the book stack or ebook queue. These are the ones I'm most interested in at present.
jackofalltradesonJune 30, 2021
I've come more interested in the way I think about/produce code in the last couple of months and am searching for something that might be a good read on it - considering I'm mainly a JavaScript developer.
I find that most of the concepts of SOLID, for example, are really hard to figure out in most of the code base of the projects I've worked/see online implemented in Node for example. It might be related to my lack of knowledge and understanding of said principles though, but I've seen a youtube video (https://www.youtube.com/watch?v=CnailTcJV_U) some months ago that showed me a "clean architecture" implementation that I've never really seen in any project I've fiddled with.
AtNightWeCodeonMay 25, 2021
droobyonMar 22, 2021
Here is Bob responding to OPs link: http://blog.cleancoder.com/uncle-bob/2020/10/18/Solid-Releva...
Stating:
“SRP) The Single Responsibility Principle.
Gather together the things that change for the same reasons. Separate things that change for different reasons.”
That’s a pretty clear delineation IMO.
checoivanonSep 16, 2010
There is a huge difference between knowing and KNOWING. Knowing your tools well enough lets you focus on the problem rather than searching how to hacking your way through. Don't be a copy paste programmer.
Don't be mislead by fast typers either.
Fast turnaround is good, but stable code is better. What's the point of finishing in 1 day instead of 2 if you'll be debugging for a week afterwards? With enough practice you'll be able to get the stable code out in the same time as the fast typer.
Some book recommendations:
-Code Complete 2.
-Refactoring: Improving the Design of Existing Code.
-Clean Code.
-Head first design patterns.
acidburnNSAonDec 23, 2018
Mandatory code review has turned out to be a great way to train newbies, write better code, and make sure code is understandable to at least one other person. It's been an investment (it's slowww) but I still think it pays dividends. That's what I'd add to this advice. And I'd tone down the comments focus. Comment only when you fail to express yourself clearly in the code.
tarasmatsykonFeb 22, 2019
Once again, good collection if you have no time to read the book. Anyway, it does not cover other parts like contracts/interfaces, the absence of comments (which can be a good sign) etc. Would recommend checking both CC books if you want to write better and maintainable code.
PS. Anyway, Dave, thank you for the popularization of best practices.
_benjonJuly 9, 2021
Clean Code is an excellent book to start going in the direction of what I'd consider "good programmer", in the sense that a good programmer writes code for humans, not for computers!
My opinion of "good programming" is just exactly that, the code is easy to read, easy to glance and figure out at a high level what it is doing.
About OOP, there are a ton of opinions regarding that (I kinda dislike it...) so don't really fret about it, a good programmer writes code that humans can easily read, that human being future you also, since a week later we often have no clue what our code does and need to read it again anyways!
Something that I've been enjoying a lot lately is investing in my tools, which for me right now is learning to use neovim, and even thought I'm not using it professionally (I think I'll never will because that might convert it into "work" and suck all the fun out of it) it has made a huge difference in my side, projects, you know, the code that I'm actually excited about!
I sympathize with you since I didn't took formal programming courses and most of the felt like I was not good, or not up to par with other or whatever... seems like my engineering manager and the previous raises disagree with me! So, don't confuse impostor syndrome with "not good"
As a last thing, I recently came across a couple of articles here in HN regarding building useless stuff[0] and homebrew tools[1], and in doing so I've been finding the joy and fun I used to have back when I was just learning!
So bottom line, don't worry about being good and focus on having fun/enjoying what you do!
[0]https://news.ycombinator.com/item?id=27256867
[1]https://news.ycombinator.com/item?id=27482397
kurtisdipoonMar 19, 2017
2. Learn to fail and feel good with that. And as above, to gain as much knowledge from that, as possible.
3. Learn to be confident enough to defend your solution.
4. Read as many non stricly technical books related to programming as possible. Ie. "The Pragmatic Programmer", "Rework", "Clean code", etc.
5. Don't take your job too serious. If you worry about your code after hours, stop! And if you can't, change your employer.
6. Everyone makes mistakes. Just try to not repeat them.
avl999onJan 11, 2021
https://sre.google/workbook/table-of-contents/
Sounds like you are unhappy with the quality of code and error handling. Seems like it was written by junior devs? I would recommend having the team read the usually recommended books if they haven't. At the bare minimun:
* Refactoring by Fowler
* Clean Code by Robert Martin
If you are using an OO language:
* Practical Object-Oriented Design in Ruby
The book has "in Ruby" in the title but it's a general purpose book on what make OO design "good"
Then follow it up with
* Patterns of Enterprise Architecture
* Clean Architecture
These books are not perfect or the be all end all, there are parts of them that might be slightly dated but they get you to a large chunk of the way to the promised land.
Lastly, if the application is working, the users are happy, there is no bug infestation and you are not having issues with releasing new features, don't feel the pressure to immediately "fix" the code.
tmalyonFeb 22, 2018
I think the first thing to consider in doing a review is first look to see if the code is easy to read and understand. There is that number out there that states we read code ten times more than we write it.
m110onMay 13, 2021
> Aren’t the first 3 or 4 chapters basically what you can find in Google’s own cloud toturials?
> Why does the domain-driven-design chapter come after you’ve tied the reader into GCP? I can’t think of a single enterprise business domain where that would make sense from a European GDPR driven perspective.
Our idea was to create a seemingly modern app based on microservices, with full GCP setup and fancy tools used. We then go on to point the issues in the code. We wanted to show how an app that seems well built on surface can have hidden problems that are hard to spot. We don't deep dive into GCP, mostly just describe the setup.
> Why do you think you can cover that many topics in a single book? I mean, part of the reason Clean Code is well liked is because it covers one topic in depth, rather than covering a bunch of different topics without ever giving the reader anything of value on any of them.
I believe you'll find a lot of value on these topics, even if we don't go super-deep into each of them. It should give readers enough ideas on how to approach building complex apps. We base this on our experience, so it's not just bland descriptions of the patterns. Also it's all focused on Go and on a real example project, so it's not abstract.
nXqdonNov 6, 2014
Long term solution: Encourage them to watch conference and good books like Clean Code, or TDD books. Those are incredibly good. Maybe they are not interested in at first, and never, but those who want to be better will become ones.
_wp_onJune 30, 2021
I'd say half the book contained good advice, the other half was mediocre or dubious at best.
I'm curious to hear what others think who've read both books.
nojokesonMay 26, 2021
I have read the book (not very recently) and I do not recall this but perhaps I am just immune to such advice.
I like his book about refactoring more than Clean Code but it introduced me to some good principles like SOLID (a good mnemonic), so I found it somewhat useful.
tjvconApr 3, 2021
You mention bugs specifically, for which I think the best remedies are good unit tests and careful consideration of edge cases (which often go hand in hand). Other smaller issues such as deviation from framework conventions and performance problems can be helped by getting to know your languages, frameworks and database better, which comes with time. More generally, there are lots of good resources out there to help you improve the readability and structure of your code - Clean Code by Robert Martin (particularly the earlier chapters) and Sandi Metz’s books and talks are both good starting points. Issues with your general approach to solving problems are harder to address, but reviewing others’ code, learning about design patterns and pair programming can all help here.
In terms of actionable advice, I’d encourage you to briefly discuss your intended approach to a problem with a colleague before starting work: this can help expose issues in advance. Even better, pair program on the implementation with another engineer. Just pairing on the review can also help to reduce the back and forth and get code shipped faster.
dazzlevoltaonJan 24, 2020
- Reading books (e.g. Clean Code, Refactoring: Ruby Edition, Practical Object-Oriented Design, ... these left a mark)
- Going to conferences (Rubyist? Attend a talk by Sandi Metz if you have a chance)
- Testing (TDD at least Unit Testing)
- Yeah, the usual stuff: quick deployments, pull requests, CI/CD ...
- Preferring Composition over Inheritance (in general and except exceptions :)
- Keeping on asking myself: what is the one responsibility of this class/object/component?
- Spending a bit more time on naming things
- Have a side-project! It's a fun way of learning new things (my current one is https://www.ahoymaps.com/ - I could reuse many things that I learnt also in my 9-5)
csnewbonNov 28, 2017
HelloNurseonMay 25, 2021
All the "bad" examples discussed in the article are rather context dependent, representing uninspired examples or extreme tastes in the book rather than bad or obsolete ideas.
Shredding medium length meaningful operations into many very small and quite ad hoc functions can reduce redundancy at the expense of readability, which might or might not be an improvement; a little DSL that looks silly if used in a couple of test cases can be readable and efficient if more extensive usage makes it familiar; a function with boolean arguments can be an accretion of special cases, mature for refactoring or a respectable way to organize otherwise repetitive code.
b93rnonJune 18, 2021
diyseguyonJuly 20, 2017
davegaueronApr 2, 2021
The Pragmatic Programmer serves as inspiration for me every time I read it. I know everything in it, but somehow I always come away with at least one "I could totally be solving my current problem with this!" insight from a re-reading.
OlognonDec 8, 2020
Clean Code has a narrative and is opinionated. It explains the experiences that formed those opinions. It is a better read.
Code Complete is dry, academic, and comprehensive for its scope. It references many studies and is well documented. It has opinions too of a sort. It is a better reference.
Thinking of function length - Clean Code says short functions are good. Code Complete references studies that say it is not long functions that are bad, it is functions using too many objects/variables that are bad. This of course has an indirect effect on function length. So I keep this in mind, and both books are helpful.
I read a bunch of Uncle Bob's books and usually don't mind him being opinionated, although I did think the opinions in Clean Coder got to be too much. Although not all of it. Recently I have been mulling the idea from that book that there should be zero regressions. I think there is something to that, if you start to accept there can be 2-3 regressions per sprint, then why not 5-7? Why not 10? I agree with him that acceptance of regressions is a problem.
mdemareonMar 10, 2009
I have two objections: First, what is "one thing"? Render a Doom 3 frame? Or increment the "i" variable? The "Clean Code" author argued that a log statement or a try/catch statement deserved its own method.
Second: says who? Where's the evidence that doing "one thing" is better than doing more things?
In general I notice that there are many rules and best practices in programming, without a lot of evidence, or even discussion of the drawbacks.
HasknewbieonJuly 25, 2017
Having read both a long time ago, I also feel like Code Complete is the one to recommend: it covers more ground, is pragmatic, and more importantly most of its recommendations are based on studies, i.e. they come from empirical evidences. Clean Code compares poorly to this, in that it's just one guy's opinion.
That doesn't necessarily mean Clean Code is a bad book, but since our work relies primarily on logic, I'd rather have arguments presented to me logically.
Since both books cover pretty much the same ground, it makes more sense to recommend Code Complete.
rluharonMay 29, 2013
I have had to try and clean up functions that were two thousand lines long (in Java), had lots of side effects, and took in seven parameters. Oh boy did I wish the developer had read Clean Code.
I agree with your premise that the book is not relevant to those who work in dynamic or functional programming languages. Frankly, I don't think they are not the intended audience. I think it is a little hyperbolic to call it the "one of the most dangerous programming books released in the last decade".
externalrealityonApr 1, 2019
The only criteria I have for good code these days is "Does it work", "Can I understand it". Everything else is a good IDE's command away for being willed into reality. So I really don't spend too much time on the "good" code debate like I did as a teen reading "Clean Code" and GOF books. I actually wish I could have that time back, I would have read, in their place, books on type theory and OS design, Posix, in other words things that actually help me build stuff and get things done and that I subsequently had to read later. Undo the damage done by the "good code" people that have me thinking about stuff that nobody cares about. Take a month off, read a book on game design in opengl, and write a cool robot simulation or something and remember how much more gratifying that is than writing a small do-nothing program just to try out some useless design pattern that doesn't scale beyond micro-examples.
There is so much varying lit out there on how to write good code that I am surprised that I am surprised if even 2 programmers can truly agree on what good code is. So Again, I'll say that "good" when it comes to code should be equivalent to "easy to understand" and "does the flow of text match the flow of program execution" in other words "is it easy to understand given I am familiar with the problem domain".
halostatueonMay 29, 2013
I distinctly remember arguments with people who were reading Clean Code at the time who really believed that one-line methods really were the ideal.
The trick is knowing what does “doing more than they should” actually mean? If you follow Clean Code as I’ve seen some people follow it (including the Ruby dev shop I mentioned elsecomment), you will end up having substantially larger interfaces at the cost of understanding just what it is that your program is supposed to do in the first place.
I’ve dealt with programs written the Clean Code way (an explosion of methods, classes, and objects), as well as programs written with too much going on in one place (e.g., 2+kloc functions). Neither is fun to deal with, but it’s generally easier to assimilate the basic business purpose of the 2+kloc function than something that has a larger interface surface than it needs to have.
fdsvnsmvasonSep 10, 2018
Robert C. Martin, Clean code: https://www.amazon.com/Clean-Code-Handbook-Software-Craftsma...
Vaughn Vernon, various: https://vaughnvernon.co/?page_id=168
Steve McConnell, Code Complete: https://www.amazon.com/Code-Complete-Practical-Handbook-Cons... 2
Clean coder: https://cleancoders.com/ videos
Hunt and Thomas, The Pragmatic Programmer: https://www.amazon.com/Pragmatic-Programmer-Journeyman-Maste...
Hitchhiker's Guide to Python: https://docs.python-guide.org/
Dustin Boswell The Art of Readable Code: https://www.amazon.com/Art-Readable-Code-Practical-Technique...
John Ousterhout, A Philosophy of Software Design: https://www.amazon.com/Philosophy-Software-Design-John-Ouste... This one looks particularly interesting, thanks AlexCoventry!
Kent Beck, Test Driven Development: https://www.amazon.com/Test-Driven-Development-Kent-Beck/dp/...
Dan Bader, Python Tricks: The Book: https://dbader.org/
Ian Sommerville, Software Engineering: https://www.amazon.com/Software-Engineering-10th-Ian-Sommerv...
Svilen Dobrev, various: http://www.svilendobrev.com/rabota/
antjanusonJuly 27, 2018
Clean Code: A Handbook of Agile Software Craftsmanship
http://amzn.to/2vcRcgU
This book really helped me focus on code organization and seeing maintainable code as an overall goal whilst building long-term applications. I'd say that one of the reasons why the work I've done 3-4 years ago can still be used, expanded, and maintained today is because of this book. Short functions, code organization, and naming conventions all stuck with me.
I'd say that unlike other programming books, this one focuses on the "art" and "organization" rather than syntax and other aspects of programming.
The Pragmatic Programmer: From Journeyman to Master
http://amzn.to/2vfeUaT
This book tackled real-world application building and practices. I'm still reading it. I liked how it tackled not only some basics of programming (resource management practices) but also project management to a certain extent. Eg. how to use prototypes, how to use "trace bullet" programs, etc.
Game Programming Patterns
I think one of my favorites has been "Game Programming Patterns" http://gameprogrammingpatterns.com/ which is free online or you can get an ebook/print version http://amzn.to/2veRdiO
The book introduces several basic design patterns, it explains WHY they're used, how to implement them, etc. in the best way I've read so far. No CS book or online article has been able to explain these patterns as this book did.
And I'm not even a game developer.
Also, check out this post on dev.to -- https://dev.to/ben/what-are-the-most-interesting-readable-so... it has some good answers! :)
t176onJuly 13, 2019
Regarding the second point: One of the hardest things to swallow is a programmer with 2 or 3 years experience pointing out code smells in my work simply because he's read Clean Code (I've been a professional, full time programmer for 30 years). Sure, there are code smells in my work - I won't deny it - I'm not a clean coder and I accept that my coding style leaves a lot to be desired. But I work hard and solve difficult problems to a clients satisfaction.
Is it just me or does anyone else think that 'code smells' is a demeaning expression?
janpieterzonFeb 27, 2016
I normally go even a bit further (certainly on the frontend) and leave duplication until I wrote something 3 or 4 times (or until it has stayed there for a little while). This ensures that when I do write my abstracted component I'm actually making sure it is something that can, at least within that app, be re-used.
I do re-use React components between different projects but am also using the same Bootstrap theme so this makes a lot of components really easy to re-use.
[1]: https://www.goodreads.com/book/show/3735293-clean-code
adamklonAug 31, 2020
I’ve posted links to this work-in-progress book a few times in the past, but I’m going to do it again because I think it fits the description perfectly.
Grokking Simplicity by Eric Normand [0] is a great book for introducing the premise behind FP in a pragmatic fashion. It doesn’t get bogged down in monads and type theory, just the benefits of pure functions and modeling applications as flows of data.
All the code examples are in JavaScript, so it requires no prior knowledge of functional programming, and it does a great job of building things up from first principals while highlighting the benefits vs a more object oriented approach.
It’s only half complete, with a nebulous completion date, but I’ve already purchased a copy, and it would the first book I’d recommend for any newcomer to FP (it’s already worth it just from the first half as far as I’m concerned).
[0] https://www.manning.com/books/grokking-simplicity
DenzelonJuly 25, 2017
I find it painful working with codebases that don't use most of the principles re:
- Write code like good stories: Code should read like a story, methodically descending the call graph method by method; each working at one level of abstraction.
For example, why is string manipulation littered all over this function that's supposed to be dealing with consolidating reports? Ugh. I like when one function stays at one level of abstraction
- Factor out conditions into descriptive methods: I shouldn't have to sit and read through 5 logical operators, some arithmetic, and method calls in 1 'if' conditional, to understand why we're doing all this.
Once again, this goes back to having your code read like a story. Factor it out into a descriptive function, so that I can understand at a glance and deep dive if necessary.
- Comments are a failure: This applies 99.99% of the time. It's almost comical when someone leaves behind a comment that could be eliminated by factoring something out into a descriptive method call instead.
There's a lot of other great stuff in Clean Code that I'm forgetting off the top of my head. (It's been awhile since I last looked over it.)
I've come across very few code bases that are a literal pleasure to read. https://github.com/jekyll/jekyll is one of the cleanest codebases that comes to mind immediately. And on the other side of the coin, https://github.com/kubernetes/kubernetes is one of the dirtiest.
If anyone wants more details/expansion, let me know and I'll reloop. (On my phone right now.)
nomorefoolsonMar 14, 2021
1. Business objectives
2. Users and use cases
3. Architecture <- design decision, performance expectation, wide picture of the system
4. Infrastructures <- you may mention environment and networks here, like k8, aws or gcp.
5. Application <- ui, flow, activity diagram, algorithm here
6. Data <- now you can place UML here
As for code level documentation, writing readable codes is enough as documentation. If some guys can understand what the codes do by reading the codes, documentation won't be needed. How to write readable codes? A good reference for this is Clean Code book. If documentation is really needed, Java Doc style is worth to follow.
Hope this helps
JachonFeb 28, 2019
Uncle Bob and friends definitely form their own "school". I think they call the "functions and assignment" style "Newspaper style", since for them it's kind of like reading a newspaper. Following it you can actually get a long way towards the dream of "self documenting code". I'm happy when people who believe in some specific school of thought get it to work for them, and even if I disagree on things at least there's consistency.
It's still never as clear as a literate program, though. And while Uncle Bob has been upgrading by learning Clojure, a lot of that school's work has assumed OO-in-the-style-of-Java5/C++98 environments. And to be fair that's a lot of the mass of legacy code we unhappily get saddled with. I think their work is less applicable and there are other schools to listen to when you have different languages or programming methods (FP, declarative, OO with a MOP, etc.).
I read the Clean Code book finally not too long ago, and while I've never argued with a book so much, there is value in it, and some programmers would do much better than their current flailing to follow its approach exactly. But these guys aren't my personal programming heroes, I'd rather be like a Norvig than a Jeffries (even if the latter is a perfectly acceptable engineer). But I can usually find value in all their works; philosophically I'm aligned with Bruce Lee, I'll take what I think is valuable and discard the rest.
criley2onMar 22, 2017
We did a book study on a book called Clean Code where I work, and I reminded of a similar situation that the book explains when describing why we all write dirty and bad code.
Why do we write bad code? Because our stakeholders and our product owners require it. Well, they push deadlines and expectations on us that mean we have to cut corners to make their promises become reality within the unrealistic time provided.
But if you ask the stakeholder why they pust that on you, the stakeholder will say "well, it's the client". Or they'll say "marketing made a promise to the client".
It's always upstream. There's always an upstream concern.
In the book they talk about making a stand, as a developer. That you have a responsibility to explain to your stakeholders and the people above you that doing something the RIGHT way is worth it. That you are the subject matter expert, that it is your responsibility to raise these concerns and thus your responsibility to write good code.
Netflix can pass the buck. "We do what we have to".
But they have a responsibility as one of the premiere web companies to do more than pass the buck.
A Good Internet doesn't happen accidentally, and it doesn't happen when stakeholders pass the buck. It happens when people make a stand for what's right and operate according to their values.
So yes, it is Netflix's responsibility not to bend Mozilla into accepting a Studio's IP demands, but to bend the Studio into accepting humanity's internet demands.
Why do we assume that Netflix can persuade Mozilla, but not a rightsholder?
Chris_NewtononJune 30, 2021
I would have liked to see Ousterhout make a more thorough argument if he was going to criticise TDD. His central criticism — that TDD results in what he calls tactical programming, prioritising the implementation of specific features over good design — is certainly defensible. However, I think he was too superficial in what he actually wrote on the TDD section, and consequently I don’t think he made a particularly convincing connection with the ideas developed earlier in the book.
I think you’re slightly unfairly misrepresenting his position on large or small classes. He makes a solid case that what he calls deep modules are better for managing complexity than shallow ones. He also identifies a correlation with size because small modules tend to be shallow. That’s not the same as arguing for large classes or against small classes just because of their size, though.
q845712onMar 31, 2021
Personally I find I still frequently write pretty atrocious code on the first draft, and it's only by stepping back from the problem after demonstrating to myself I understand it well enough to solve it at all that I can begin to write a more graceful solution. But deadlines and reality being what they are, I think the majority of us are embarrassed by our past code a majority of the time.
So don't be too hard on yourself, but also frankly don't worry about shoe-horning yourself into "A Career" either. They're kind of a recent invention and the whole concept might need a few more iterations. You could spend a few years as a Product Manager, an Engineering Manager, a Highschool Teacher, or a Business Analyst, leveraging your past experience to gain competency in a new niche.
I want to emphasize of self-awareness you have is commendable and not universally present: If you can realistically assess your own current skill level and then apply yourself to improving, you could be an above average software engineer before you know it. And right now it seems like so so many companies just can't get enough software engineers, so it's a pretty safe place to practice learning how to learn while also earning a decent income.
phesonOct 8, 2016
https://neil.fraser.name/news/2015/04/13/
But like others in this post I would recommend CS unplugged.
And depending on how long he is in there for he might want to look at:
How to Design Programs - This is a good book, and although it's in Scheme, it teaches how to create appropriate levels of abstraction, which seems to be something many programmers struggle with.
Concepts, Techniques & Models of Computer Programs - Discusses the different paradigms and how they are inter-related.
Also something a bit more vocational like The Pragmatic Programmer or Clean Code / Clean Coder probably wouldn't hurt either.
If he can read all of those he will be very well prepared to do some actual programming when he gets out.
SICP not a bad shout either, although I've not got past the first chapter.
kdazzleonMar 8, 2017
The only downside is that reading books doesn't help you learn new languages or frameworks.
Screw the github graph.
tdbgameronOct 31, 2017
I did read Clean Code by Robert Martin. He's definitely in the "die hard TDD guru" category, but there are still useful examples to be extracted from the book.
Besides that, I mainly learned a lot of testing tricks in the wild, reading through Github projects. My learning process now-a-days is mostly:
1. Discover a really cool trick or concept I didn't know existed in a Github project.
2. Research the hell out of it.
3. Try to use it in some personal example project.
rovolutionaryonNov 6, 2014
Also direct them towards resources where they can learn clean code practices. Perhaps institute a monthly "book club" where you select books about good coding practices. I would suggest starting with Clean Code by Robert Martin
simonsayssoonMay 26, 2021
I see a lot of people in here acting like all the advice in Clean Code is obviously true or obviously false, and they claim to know how to write a better book. But, like you, I will continue to recommend Clean Code to new developers on my team. It's the fastest way (that I've found so far, though I see other suggestions in the comments here) to get someone to transition from writing "homework code" (that never has to be revisited) to writing maintainable code. Obviously, there are bad parts of Clean Code, but if that new dev is on my team, I'll talk through why certain parts are less useful than others.
denizozgeronJuly 23, 2014
- The proper use of comments is to compensate for our failure to express ourself in code. Comments are always failures. We must have them because we cannot always figure out how to express ourselves without them, but their use is not a cause for celebration. So when you find yourself in a position where you need to write a comment, think it through and see whether there isn’t some way to turn the tables and express yourself in code.
- The older a comment is, and the farther away it is from the code it describes, the more likely it is to be just plain wrong. The reason is simple. Programmers can’t realistically maintain them.
- Comments Do Not Make Up for Bad Code! One of the more common motivations for writing comments is bad code. We write a module and we know it is confusing and disorganized. We know it’s a mess. So we say to ourselves, “Ooh, I’d better comment that!” No! You’d better clean it! Clear and expressive code with few comments is far superior to cluttered and complex code with lots of comments. Rather than spend your time writing the comments that explain the mess you’ve made, spend it cleaning that mess.
```
// Bad:
```
flurdyonApr 27, 2015
And similarly unfortunately the majority I encounter don't read many if any books. If people only read books then that is perhaps an issue as well. And reading a specific technical book about a specific software version is also usually a waste of time in my opinion. Read howtos online and experiment away instead.
I do tend to interview more mid-to-senior level of which how they keep up to date is more relevant. I am not expecting new grads to have read the entire backlog of Pragmatic bookshelf if any. Nor am I expecting anyone to have read the bricks (gang of four, Fowler's application patterns etc) cover to cover. But for example seniors not having heard of these bricks or the Clean Code and Pragmatic Programmer books is a red flag. If they know of them but disagree with them then that is fine, but not heard of them at all is weird.
In a previous job they sent me Clean Code and a couple of other books in the post to read a few weeks before I started. Which was a good sign that I was joining the right company, even if I had already read them all previously :)
copyconstructonAug 11, 2017
That's primarily the reason why there are no "concrete examples", because one person's concrete example is another person's definition of contrived. Splitting hairs over some toy example wasn't something I thought would buttress the ideas presented, though I can imagine why some might need that scaffolding to follow along.
Re resting - here are some points the article makes about how smaller functions can in some cases hurt testing:
1) "Furthermore, when the dependencies aren’t explicit, testing becomes a lot more complicated into the bargain, what with the overhead of setting up and tearing down state before every individual test targeting the itsy-bitsy little functions can be run."
Disambiguating this for you, one of the myths of smaller functions is that they are easier to test. The article makes the claim that this isn't always true, because many who wax lyrical about the beauty of smaller functions also champion for fewer arguments to be passed to the function. The book Clean Code very explicitly states this (read the book, not as a how to guide but as a cautionary tale), and many a time what I've seen happen in the wild (especially in Ruby) is that programmers who like small functions and don't like making deps explicit - which then means the code (and ergo tests) rely on setting up shared global state.
Of course one can write smaller funcs with fewer args and not do this, but that's not the point here. The main argument is that making functions smaller doesn't always make it easier to test.
The article also does provide two examples when having the smallest possible function does help in testing. I'm not going to rehash those arguments again here.
SwizeconAug 3, 2021
A similar effect can be found with Grit, Fogg’s Behavior Model, Superforecasting, and most Gladwel books.
On the coding side, I’ve only noticed this with Pragmatic Programmer, Clean Code, and maybe Phoenix/Unicorn project. Could I don’t read enough of those or they’re too focused on specific technologies instead of broad ideas … or I get too much of my technical reading from blogs and twitter. Those do get repetitive and you quickly find common patterns, but no titles to refer to.
Chris_NewtononDec 22, 2020
I agree up to a point, but I find this kind of separation a little… idealistic? I prefer the principle that any abstraction should hide significantly more complexity than it introduces.
At the level of system design, there probably are some clearly defined layers of abstraction. I’d agree that mixing those is rarely a good idea.
But at the level of individual functions, I have too often seen numerous small functions broken out for dogmatic reasons, even though they hid relatively little complexity. That coding style tends to result in low cohesion, and I think the cost of low cohesion in large programs is often underestimated and can easily outweigh the benefit of making any individual function marginally simpler. If you’re not careful, you end up trading a little reduction in complexity locally for a big increase in complexity globally.
rajuonOct 2, 2008
Personally, I read a lot, and write some code. I need to write more code than I read, but its a good start. And a lot of what I read does not have to be necessarily technoloy specific, rather books like "Clean Code" and "Code Complete", Intro To Algorithms etc, patterns, architectures etc.
I also tend to read a lot of self-help (GTD), business (Good to Great) and career specific books (Career Intensity) and similar blogs and sites.
In my experience, it helps to try and really really practice something. As Bruce Lee once said, "I fear not the man who has practiced 10,000 kicks once, but I fear the man who has practiced one kick 10,000 times."
To give you an example, I am currently reading Clean Code, and one of the pieces of advice is "A method should do one thing, and one thing only". Nothing new there, but normally I do take the time and effort to keep my code short and clean, but this book says that exception handling (in Java) IS ONE thing. So your method should not attempt to do exception handling as well as some other piece of functionality. For the past 3 days at work, I have tried to do that, not because the book says it, but because I did not think of it that way, and I want to give it a whirl before I make my mind up.
A lot of people I know don't read, and even those who do, don't practice it. If you want to grow - learn, practice, measure, then either accept it, or throw it away.
Update - Other HN readers have other pieces of advice that I did not add here. But working sample projects, reading documentation, tutorials online (I refer to them as the magazine version of tech books :D) all help
JachonDec 13, 2018
The Earth is Enough (recommended if you like trout fishing)
Clean Code (recommended if you want to invigorate your desire to write better code, there was a lot to both agree and disagree with though for me anyway)
Game Engine Black Book: Wolfenstein 3D (recommend if you want to study the details of an early 3d game engine, or details about the 386 that made it so hard to do games with)
Miss Kobayashi's Dragon Maid (this is the first manga series I've read, because I was obsessed by the anime for a while and wanted more, so would only recommend if you like the anime)
Land of Lisp (only recommended if you want a fun sort of scheme-ish style approach to seeing some of the features of common lisp in a simple mostly text based games setting)
The Age of Em (recommend if you want a careful and detailed analysis of what a possible future looks like should humans get mind uploading technology)
A Critique of Democracy (recommended if you want to have a chance of winning bar arguments, not the best for deeper thinking)
The End of Eternity (fun sci-fi from Asimov)
The Three-Body Problem (book 1 of (I found out after starting (again)) 3 -- good enough that I'll read the next two, but not good enough that I had to go out and get the second book immediately like other series I've read)
Beyond Happiness (meh, wouldn't recommend)
Ninefox Gambit (book 1 of (I found out after starting) 3 -- if you like "armchair playing war" sci-fi you'll probably like this more than me, but I'll get and finish the next two books at some point)
More detailed short thoughts + older reads if desired: https://gist.github.com/Jach/1610886 Maybe I'll wrap up one of the several in-progress ones before the month is out, too.
memracomonOct 9, 2013
Some alternate choices that could be OK if you can find at least one good developer to lead the team, are Clojure, or Erlang/Elixir. With the Erlang virtual machine, RabbitMQ would not be necessary, although I like it because it gives you a lot of points where you can measure/monitor the internals of your application. I would also seriously look at adding Apache Camel to the mix even though Akka does not require Camel to integrate actors. But Camel is a thin layer that makes it easier to reconfigure integration points.
Ao7bei3sonAug 29, 2017
My favorite example: Overdoing the short functions thing. I've seen this a lot. Unsurprisingly, considering that for most devs, when you ask them what makes good code, "short functions" seems to be the first thing that comes to mind.
Splitting code into extremely short functions has a few disadvantages too: a) in what order they're called is not immediately clear, b) where they can be called from is not immediately clear, c) going up/down the stack can make it harder to follow when debugging interactively. d) It increases the LOC and noise. And e) especially in OOP languages, short methods make it more tempting to turn variables into attributes to avoid passing them around explicitly (bad due to longer lifetime).
Splitting functions should only be done if it makes sense semantically. Each function should make sense on its own. If some logic is highly cohesive (e.g. because it implements a specific algorithm), not independently reusable, and it's subblocks only make sense in one order, and it all fits on a few screenfuls, it might make sense to keep it in one longer function instead of dividing it into fairly arbitrary chunks.
hendrikmakaitonApr 23, 2021
A few classics that focus on improving "general code style" would be:
- "Clean Code" (https://www.oreilly.com/library/view/clean-code-a/9780136083...)
- "The Pragmatic Programmer" (https://pragprog.com/titles/tpp20/the-pragmatic-programmer-2...)
EDIT: Since you are talking about coding like at a top company, one book that has been sitting on my shelf for a while, but I haven't gotten around to reading yet is "Software Engineering at Google: Lessons Learned from Programming Over Time" (https://learning.oreilly.com/library/view/software-engineeri...)
nstartonSep 18, 2014
I do agree with the sentiment that real world code examples are more useful. When I was learning design patterns during my degree, we were actively discouraged from using Head First as THE reference even though it did simplify things. Our lecturer was later challenged on this view. He then took the students on a counter challenge to refactor and redesign code from real world examples (taken from students' projects). Reality hit quite hard for a lot of us as we struggled to see the patterns in less obvious situations.
An interesting point to note however, was that after gaining an understanding of the design patterns at a practical level, I could then reference simple examples as given in Head First and immediately formulate how I would use it to solve a practical scenario that I might have been stuck with. Funny how it worked one way but not the other.
devuatlonDec 21, 2011
I joined a small team at a startup. Those guys did their best to make me produce quality code as soon as possible. They were reviewing my code several times a day, and teaching me what to do to, to make it efficent, easy to understand and well designed. Early on they even made me read the "Clean code" and I am eternally grateful for this.
Now I think part of being self-taught is actually having to find teachers on your own. Software Engineering is always about knowledge - whenever you code, you're probably solving a problem, which hasn't been solved before. Otherwise you'd just use some library to do the trick. It means that programming is about inventing new stuff, and so when you tell someone about your code, you're actually teaching them about it. Whenever you join a new project, someone has to teach you how to work with their system. If you're independent contractor building software for your client, you have to learn their ways of doing business.
High tech jobs are all about knowledge transfer, this way or another.
During my college I didn't learn that much from my professors, when it comes to software engineering in the trenches. I did learn a lot during college though. It was a time of meeting other people who were passionate for technology. We could exchange our insights, and do college projects our way. We would give each other feedback on our work, and so we were actually teaching each other.
I think above applies to meetup groups, code retreats and similiar initiatives. Programmers gather together to learn. Software engineering is all about knowledge transfer, and you have to want to learn, but it doesn't mean there's nobody to teach you. You just have to find your teachers on your own.
You are self-taught, but never alone!
technofireonJuly 20, 2017
The second thing that has really influenced my coding style for the better (making it clearer and easier to understand) is writing a medium-sized program using a strictly functional language like Erlang. This will force you to use global state less, to write functions in such a manner that the function itself includes all the information required to understand it, simply because global state cannot be used and everything on which the function operates must be passed into it explicitly via its parameters.
[1] Clean Code (Robert Martin)
http://amzn.to/2uewcpB
[2] Refactoring (Martin Fowler)
http://amzn.to/2vnD7vx
ggambettaonOct 2, 2014
Modern C++ Design (Andrei Alexandrescu)
The Screenwriter's Bible (David Trottier)
Clean Code (Robert Cecil Martin)
Il Codice da Vinci (Dan Brown)
The Anatomy of Story (John Truby)
A Random Walk Down Wall Street (Burton Malkiel)
The Power of Habit (Charles Duhigg)
jlaroccoonApr 22, 2013
The beginning of Part 1 looks more like a beginner programming book than a C++ book. They're important topics, but none of them are specific to C++, and they're not the reason I'm buying a C++ book.
The rest of Part 1 looks like a rehash of "Code Complete" and "Clean Code." There are already good books on those subjects, and I'm not seeing what this one adds. Might be interesting to the same people who don't know about SCM and compiler warnings, but I'm not in that demographic, and even they are probably better off in the long run going with other books.
Part 2 looks interesting, but not enough to buy the first half of the book along with it. There are other books on writing reliable multi-process/multi-threaded code (both in general and in C++), and my impression is they would go into more depth than a book that tries to be as broad as this one.
I should point out I was already predisposed to say "no" because my preference is to avoid books that tie themselves to a specific language unless I'm learning the language or the particular language has an unusual advantage for a particular thing (such as Erlang for reliable multi-processing). Unfortunately neither of those apply here, so I'd prefer the more general books on these topics.
thebackuponMay 25, 2021
Now over 10 years later I have come to realize that you cannot set up too many rules on how to structure and write code. It is like forcing all authors to apply the same writing style or all artists to draw their paintings with the exact same technique.
With that analogy in mind, I think that one of the biggest contributors to messy code is having a lot of developers, all with different preferences, working in the same code base. Just imagine having 100 different writers trying to write a book, this is the challenge we are trying to address.
konradbonFeb 26, 2013
However to turn things a bit more constructive, let me know what languages you see as less of a mess if you have the time. It doesn't matter whether we agree and I'm not looking for a fight, just your opinion and reasoning. I might well agree.
DanielBMarkhamonSep 1, 2009
-----------------------------------------------------------
On my Kindle:
Anna Karenina, Tolstoy; Clean Code, Uncle Bob; Palm WebOS; Antoninus Meditations, Marcus Aurelius, Emperor; Never Eat Alone, and Other Secrets to Success, Ferrazzi
-----------------------------------------------------------
In my stack:
Daniel-X, James Patterson; Born To Run, Christopher McDougall; The Existential Jesus, John Carroll; Fear and Trembling - Repetition, Soren Kierkegaard
-----------------------------------------------------------
On the way in from Amazon:
The Trusted Advisor, Maister; Secrets of Consulting: A Guide to Giving and Getting Advice Successfully, Weinberg; Rain Making: Attract New Clients No Matter What Your Field, Harding
-----------------------------------------------------------
I'm thinking about growing another pair of eyeballs so I can read two books at once. I'll let you know how the genetic engineering goes. (grin)
valbacaonMay 25, 2021
I find that these two books are in many recommended lists, but I found them entirely unforgettable, entirely too long, and without any "meat."
So much of the advice given is trivial things you'll just figure out in the first few months of coding professionally.
Code for more than a week and you'll figure out how to name classes, how to use variables, how scope works, etc.
The code examples are only in C++, Java, and Visual Basic (ha!). Completely ignoring non-OO and dynamic languages.
Some of the advice is just bad (like prefixing global variables with g_) or incredibly outdated (like, "avoid goto"? Thanks 1968!).
Work on a single software project, or any problem ever, and you'll know that you need to define the problem first. It's not exactly sage advice.
These are cherry-picked examples, but overall Code Complete manages to be too large, go into too specific detail in some areas, while giving vague advice in others.
All books are written in a time and a few become timeless. Software books have an especially short half-life. I think Code Complete was a book Software Engineering needed in 2004, but has since dropped in value.
I will say, that Code Complete does have utility as a way to prop up your monitor for increased ergonomics, which is something you should never ignore.
I have similar issues with Clean Code. One is better off just googling "SOLID Principles" and then just programming using small interfaces more often and use fewer subclasses.
A better alternative is (from above) The Pragmatic Programmer (2019), a good style guide, and/or get your code reviewed by literally anyone.
programminggeekonMay 29, 2013
In reality, Uncle Bob's stuff is actually better when taken holistically and when applied together, but it's hard to do and when taken to their logical conclusion, it is so outside the norms of OOP, that people freak out about it not being "proper OOP" as they were taught in university and in mainstream things.
mbaumanonSep 4, 2017
What I do find useful is listening to books on practice or management. Something like The Pragmatic Programmer, The Practice of Programming, and Clean Code. These are high on substance but (relatively) low on examples, so I feel I can still benefit from their insights without having to be in front of a screen.
rosspackardonNov 9, 2016
When CS majors or programmers estimate how fast/efficient code is they generally are intuitively applying big 'O' notation or some similar concept. This can be gained from an intro level algorithms class. Or you could look up and read about the topic.
The classical coding interview questions mostly stem from an intro algorithms and data structures class. Or you could get a book on interview prep and work through a couple a day.
Finally, the coding style issue usually is ancillary knowledge and not found (or at least not done well) in typical CS curricular. I would suggest the book "Clean Code" by Robert Martin. It goes through code smells, commenting, general style, and is well written.
So overall, you could look at Algorithms and Data Structures MOOC's. Also read a book on CS interview prep and writing maintainable code. Hope this helps a little. Good Luck!
SideburnsOfDoomonJune 14, 2012
Not entirely, anyway. You can't turn the whole app into a good one in any reasonable time, but when you fix a bug, take time to apply the boy scout rule ( http://www.informit.com/articles/article.aspx?p=1235624&... ) Don't put that down as a separate task that your management can approve or deny, it's part of doing the job of coding properly. That way, at least the buggy parts of the app get better.
You should not be focused only on your career when making coding and tech decisions, but look at it this way: in a year's time, you're in an interview for a job you really want. What are you going to say "I can read and maintain shitty code" or "I can make shitty code better"?
Also consider: documenting your app's architecture (or lack of it) and conventions (or lack of them).
Also consider: reading up on architecture, testing, refactoring and code quality. If nothing else, these will help you get your next, better job. Off the top of my head, try "Domain Driven Design" by Eric Evans, "Growing object-oriented software guided by tests", "Refactoring" By Martin Fowler, and on the last topic "Clean code" by Robert Martin and "Code Complete" by Steve McConnell
Big ball of mud apps (http://www.laputan.org/mud/ ) may be common, but it doesn't have to be that way - you can learn some pitfalls to avoid
UglyToadonJune 24, 2019
I understand the arguments for 'Uncle Bobifying' code but I think, as the article says, there's a balance to be struck. It's highly likely the next time I see your code (or my code if I'm coming back to it a month or two later) is when I need to fix a problem with it. While it's useful to have it split up into logically discrete chunks with sensible naming these 2-4 line functions far increase the mental load of the code.
Given I'm debugging the code because there is presumably a problem with it I can't trust these sensibly named functions to do what they say, I need to check their internals to reason about changes in application state. Though well named functions at least help the maintenance programmer reason about the why they're equally liable to code rot as the comments they replace.
As in all things there's a balance to be struck but I'd rather see a 20-30 line method than jump between 5 files because someone has read Clean Code recently.
blindhippoonNov 25, 2013
The Pragmatic Programmer by Andrew Hunt & David Thomas
Code Complete 2 by Steve McConnell
Clean Code by James O. Coplien
Test Driven Development by Kent Beck (save this for last)
These books will teach you how to think and approach coding in a way that will make Object Oriented programming simpler to comprehend.
I can't suggest a book that explains basic OOP principals, hopefully some other much smarter person here can. I learned basic OOP through practice and through my education/class - but to be honest the basics are dead simple. It's only when you start getting into the very abstract that OOP starts to get really complicated and that's where the above books will help you.
breckonJuly 4, 2019
One I'd recommend is "Eloquent Javascript". It may be a tiny bit out of date now (I read it over 5 years ago maybe, and Javascript has improved a lot since then), but it's a solid book.
Other books you might like: Pragmatic Programmer, Pattern on the Stone, Clean Code, Mastering Regular Expressions.
coldteaonDec 10, 2019
Check the PRs and read the existing code from others inside the company. Presumably those meet the company's standards, and will give you hints how to structure yours.
Read a couple of industry standard books like Clean Code and Code Complete too.
memracomonSep 11, 2013
jacques_chesteronAug 20, 2012
Anyhow, I expect we'll get the usual round up here. Code Complete, of course; plus a smattering of rebels who think it was boring or irrelevant. The Pragmatic Programmer will receive universal praise, especially from those who didn't take the time to read Code Complete from cover to cover.
Some of the debate will be about whether Code Complete is "better" than Clean Code or not. A silly argument, they are complementary (though, really, is this even a debate worth having? Code Complete is clearly the better book).
Let's see, what else?
Structure and Interpretation of Computer Programs will get mentioned, which will spawn a fertile subthread arguing about whether computer science books really belong on a list for developers. That subthread will debate the merits of Introduction to Algorithms vs everything else, and someone will mention a lisp book that changed their life. Probably Paradigms of Artificial Programming or On Lisp.
The Gang of Four will get nodded at. Like the Bible, Homer, or Peopleware it will be the book everyone says they've read but which almost nobody has actually read.
The C Programming Language will be mentioned. These days that means Zed Shaw will be named and hilarity will ensue.
Myself? I'd definitely have Code Complete (I still have my first edition), perhaps A Discipline for Software Engineering and Software Estimation: Demystifying the Black Art. I've found pretty much everything from Dorset House to be worth my time, so to PeopleWare I'd add The Deadline and Adrenalin Junkies and Template Zombies.
What we don't do in this industry, however, is read more widely. Get out of your rut. Read about history, read some classics, read deeply in another field you pursue as your hobby. Everything illuminates everything. Get out there, see the intellectual sights (for which, get a copy of Dawn to Decadence by Jacques Barzun for a guided tour). You'll be a better developer and a better person for the trouble.
KovahonMay 27, 2019
Talking about syntax highlighting, I edited my editor to treat @Todo and similar comment additions in the same way as errors: they do not belong thete and should be fixed as soon as possible. Marking them ass errors led to several small fixes.
After reading this article I might try the same with regular comments.
wglbonJune 9, 2011
Uncle Bob's book Clean Code demonstrates very small methods in C#, and it does go in the direction of looking for language constructs. It is just harder to get there in a non-lisp language.
Regarding OO in general, I am a former proponent of OO--in fact taught (delivered might be a more accurate description) the Rational Unified approach several times, brought OO thinking to several business units. Reading PG and getting heavily into Lisp took me away from that.
I think we disagree slightly on "whole program complexity" and the increasing complexity of shifting it around.