Found 19 comments on HN
technofire · 2017-07-20 · Original thread
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

peller · 2016-12-11 · Original thread
There's always the classics:

https://www.amazon.com/Design-Patterns-Elements-Reusable-Obj...

https://www.amazon.com/Refactoring-Improving-Design-Existing...

EDIT: And it appears the website is a direct rip-off of these books.

goo · 2016-11-04 · Original thread
Here is some insight that has helped me, some my own advice, some paraphrased from other sources, and I credit the source when I have it in my notes:

- There is no "silver bullet" for managing the complexity of user needs. Instead, (good) software is characterized by not a static state of "solving the problem", but a continuous refinement-- an existential struggle against incidental complexity.

- Have a very positive mindset, and inspire the same in your team.

- highly reliable websites for small companies: http://www.kalzumeus.com/2010/04/20/building-highly-reliable...

- Learn your debugging tools well: Get good at Chrome Debugging tools, pdb, visual studios debugger, or whatever the debugging environment is for your project.

- “… never consider your education complete or your opinion above questioning regardless of your title, your years of experience, your awards and accomplishments, or anything else that isn’t rational argumentation or evidence. Retaining a healthy degree of humility, constantly striving for improvement, and valuing objective metrics above subjective considerations will go a long way ..." (http://www.daedtech.com/how-software-groups-rot-legacy-of-th...)

- This is a marathon, not a sprint.

- Practical engineering advice: https://www.quora.com/What-are-the-best-kept-secrets-of-grea...

- Read books. I can especially recommend Refactoring by Martin Fowler and The Pragmatic Programmer as a more introductory text (affiliate links: http://amzn.to/2ekPnTL and http://amzn.to/2ekJQMK). Understanding why and how to do scrum effectively is really important too -- I waited too long to read a book that laid that out for me (http://amzn.to/2ekPxul)

- Good programming advice from Kent Beck: https://www.facebook.com/notes/kent-beck/mastering-programmi...

- Eventually, you will have to choose between engineering management and continuing to be close to technology. Trying to do both is a recipe for burnout. Some people might be able to do both simultaneously without trouble, but you're probably not one of them.

- Always be looking for ways to remove yourself as a bottleneck. This needs to be done both on a technical level and on an organizational level.

- Push back as necessary against demands of your time and energy that are not in harmony with your needs as a technologist.

- Good programming comes from good habits. (in that vein: copy-and-paste is the devil.)

- Seriously, read books. It's incredible how much good advice is out there.

mavelikara · 2016-08-03 · Original thread
For a professional programer, if Beck is deemed "unsuccessful", I don't know who among us you will call successful.

If you are a professional programer in 2016, you very likely are familiar with the term "refactoring". This term was placed in our vernacular by the book "Refactoring: Improving the Design of Existing Code" by Martin Fowler [1]. In the Preface to the book, Folwer writes:

    Once upon a time, a consultant made a visit to a development project. 
    The consultant looked at some of the code that had been written; there 
    was a class hierarchy ..

    ...

    I must admit to some bias here. I was that consultant. Six months later 
    the project failed, in large part because the code was too complex to 
    debug or to tune to acceptable performance.

    The consultant Kent Beck was brought in to restart the project, an exercise 
    that involved rewriting almost the whole system from scratch. He did several 
    things differently, but one of the most important was to insist on continuous 
    cleaning up of the code using refactoring. The success of this project, and 
    role refactoring played in this success, is what inspired me to write this book, 
    so that I could pass on the knowledge that Kent and others have learned in using 
    refactoring to improve the quality of software.

    ...

    In this book I describe the fruit of a lot of research done by others. The last 
    chapters are guest chapters by some of these people. 
    ....
    I've left the final word, Chapter 15, to the master of the art, Kent Beck.
    
    
You might also have heard of xUnit style of testing. Beck had a hand in many of these frameworks.

TL;DR - pay heed to the history of your profession.

[1]: https://www.amazon.com/Refactoring-Improving-Design-Existing...

jimbokun · 2015-06-22 · Original thread
I disagree with the premise that organizing code is not a recognized or appreciated skill among developers.

At least not since this was published:

http://www.amazon.com/Refactoring-Improving-Design-Existing-...

Martin Fowler really struck a chord all the developers trying to do the right thing by cleaning up badly structured code, by giving the practice a name and explaining why it's important. Refactoring is definitely a widely acknowledged and accepted practice today, although probably more so in some communities than others.

sushpop · 2014-07-07 · Original thread
"Refactoring: Improving the Design of Existing Code" http://www.amazon.com/Refactoring-Improving-Design-Existing-...
nthj · 2013-04-23 · Original thread
Note I said -refactor-, not -rewrite-. I am not a fan of rewriting apps: developers always underestimate the complexity involved, and then business rules change along the way, and it's just a mess.

Refactoring is when you rework a specific section of code, usually that you're about to work on, or just worked on, to be cleaner. It's a long-term approach, and it's how large applications stay maintainable over the long term. For your specific example, you'd leave your app alone. You wouldn't rewrite it, or touch it, until you find a bug, or need to add a new feature, and then you'd rework anything you need to to add the feature cleanly.

On a related note, Refactoring by Martin Fowler is a great book, and I'd recommend everybody pick up a copy. It's a beautiful hardcover and looks great on a shelf, too.

http://www.amazon.com/Refactoring-Improving-Design-Existing-...

Confusion · 2012-08-26 · Original thread
As the link by lttlrck also advocates: throwing shit out can easily be a mistake. More usually, http://www.amazon.com/Working-Effectively-Legacy-Michael-Fea... + http://www.amazon.com/Refactoring-Improving-Design-Existing-... can get you further, faster. Stuff keeps working while you incrementally improve it.
Refactoring: http://www.amazon.com/Refactoring-Improving-Design-Existing-...

Read it. Learn it. Love it. Make it a habit that is so ingrained you do it automatically.

Extract method: do it reflexively.

irahul · 2012-06-11 · Original thread
> Perhaps you could name this mysterious IDE

Is it just you, or does everyone using eclipse take "what eclipse does" to be refactoring?

I didn't mention IDE even once. A small part of refactoring can be done by eclipse. Rest of it is to be done by the programmer.

I am not a Fowlerian, but this is the only reference I could find. http://www.refactoring.com/catalog/index.html

Eclipse helps with a small subset - rest has to be done by the programmer. And most of it is easier to do in Ruby than in Java.

Compare the ruby edition http://www.amazon.com/Refactoring-Ruby-Edition-Jay-Fields/dp... to the java edition http://www.amazon.com/Refactoring-Improving-Design-Existing-...

On an average, ruby code ends up easier to modify and concise.

Anyone have recommendations about the linked book?

Refactoring: Improving the Design of Existing Code http://www.amazon.com/Refactoring-Improving-Design-Existing-...

Read Refactoring.

http://www.amazon.com/Refactoring-Improving-Design-Existing-...

In my view it is the single most important programming book in existence. Yes, other books will teach you other, incredibly important things. Other books will teach you the specifics of one technology or another. Other books will open up your mind on the very nature of programming (especially learning functional programming). And other books will teach you all of the incredibly important stuff that isn't siting at a keyboard and typing in code. But personally I'd rather work with someone who thoroughly groks refactoring even over someone who thoroughly groks functional programming.

MarkMc · 2011-08-23 · Original thread
I think the best introduction to object oriented design is shown in the first chapter of Martin Fowler's book "Refactoring". He gives the example of a DVD rental shop that has to calculate the rental fee based on the type of DVD: - A New Release is $3 per day - A Children's DVD is $1.50 for three days, then $1.50 per day after that - A Standard DVD is $2 for two days, then $1.50 per day after that

http://www.amazon.com/Refactoring-Improving-Design-Existing-...
dbingham · 2010-10-07 · Original thread
The only way to learn how to program is to just do it. Pick a language. Start with small programs. Learn the features and syntax of the language. When you feel you know the language well enough to write a program that uses most of its features, then pick an open source program and learn its code. Make some modifications to it. When you feel you're pretty comfortable in one language, pick a new language.

Rinse repeat. You'll find that once you have one language down, the process will go much faster with the second. The features and syntax of most languages are pretty similar.

You can pick any language you like to start with, but personally I'd recommend starting with a hard typed compiled language rather than a dynamic language. Dynamic languages are easy to learn, but its easy to be a lazy and bad programmer in them. They let you get away with too much. Hard typed compiled languages are a) much better at catching your errors and b) much harder to be a lazy programmer in. They don't let you get away with things nearly as much.

I'd recommend Java, seems to be the language a lot of people start with. It will also give you a good founding in open source programming. I started with C/C++ and I'm glad I did. But that was more of a challenge - had to learn pointers and memory management in my first language. And after that I took a little while to learn the open source mindset, since I'd started in a procedural language.

Once you have a good grasp of an object oriented language like Java (or Python) and what object oriented programming means, then I'd recommend reading the Gang of Four book on Design Patterns (http://www.amazon.com/Design-Patterns-Elements-Reusable-Obje...) and Martin Fowler's book on Refactoring (http://www.amazon.com/Refactoring-Improving-Design-Existing-...). Those will give you a pretty good basis in software design and maintenance.

In terms of recommended reading for learning a language, the O'Reilly books are nearly always good in my experience. Here's one for Java (Learning Java: http://www.amazon.com/Learning-Java-Patrick-Niemeyer/dp/0596...) and here's one for Python (Learning Python: http://www.amazon.com/Learning-Python-Powerful-Object-Orient...)

I cannot stress this enough: learn refactoring, http://www.amazon.com/Refactoring-Improving-Design-Existing-...

You will simultaneously learn:

- terminology and models relevant to software design and construction at every level

- principles of good coding and how to tell good code from bad

- the ability to redesign code as needed

- the experience and knowledge necessary to approach coding with confidence

All of these are the most critical tools you need to transform yourself from someone who sorta-kinda knows a few principles of coding to someone who groks software construction.

If I had to choose between a co-worker who truly groked the principles of re-factoring and a co-worker who had a PhD in Computer Science I would choose the former every time. It's really that important.

amichail · 2007-07-13 · Original thread

Get dozens of book recommendations delivered straight to your inbox every Thursday.