Home Forums Kamanja Forums Data Science & Models 42 lessons learned on good coding

This topic contains 0 replies, has 1 voice, and was last updated by  Greg Makowski 1 year, 2 months ago.

  • Author
    Posts
  • #23645 Reply

    Greg Makowski
    Moderator

    What are the greatest programming tips and tricks you have learned on your own by years of coding?  Jerome Terry, Software Developer, St. John’s, Newfoundland.  I can’t really claim I’ve learned the following lessons on my own. As the famous Newton quote goes “standing on the shoulders of giants”.  I’ve learned these lessons by hard work, and reading everything I could get my hands on over the course of the last 17 years – 5 years of university, 12 years programming.  These lessons have served me well. Hopefully they are helpful to you as they are to me.

    https://www.quora.com/What-are-the-greatest-programming-tips-and-tricks-you-have-learned-on-your-own-by-years-of-coding

     ————————————————–

    Iterate. Successive refinement is how we get to great code and great products.

    Simpler is usually better. Watch Rich Hickey’s talk Simple Made Easy, and read Kent Beck’s Xp Simplicity Rules.

    Don’t be clever. Don’t try to write complicated code on purpose to show how smart you are. Write simple, clear, reusable code. Think Simplicity, Clarity, Generality. Read “The Practice of Programming” by Brian Kernighan and Rob Pike. Speaking of Brian Kernighan, also read “The C Programming Language” by Brian Kernighan and Dennis Ritchie.

    SRP (single responsibility principle) and DRY (don’t repeat yourself) principles go a long way towards clean code. Read “Clean Code” by Uncle Bob Martin (Robert C. Martin)

    You ain’t gonna need it (YAGNI) applies most of the time. In general, just design for today’s requirements, to prevent over engineering. Having said that, sometimes it’s necessary to design for future growth. There’s a balance – it’s up to you to find it.

    Code with obviously no bugs is immensely better than code with no obvious bugs.

    Being able to reason about your code is paramount to high quality.

    Requirements are rarely cast in stone. As an engineer/programmer, you have a responsibility to question things that look unclear, in doubt and questionable.  Sometimes when people don’t like the questions, you really need to question more intently, though possibly with careful discretion. (Courtesy of Bryan Kelly)

    Start with why. Watch Simon Sinek’s talk How great leaders inspire action

    Clients don’t really know what they want, and that includes your manager. It’s your job to elicit their true needs.

    Despite what process you follow, some amount of up front design is required – how much should be proportional to complexity. Read “Domain Driven Design” by Eric Evans.

    Design patterns aren’t used as much as you’d think. Recognizing common patterns is important. Don’t treat patterns as a hammer looking for a nail. Read “Refactoring to Patterns” by Joshua Kerievsky. Read Steven Grimm’s answer to What are the most important design patterns that software engineers should know to work at Google, Amazon and Facebook?

    SOLID principles (Single Responsibility Principle, Open/Closed Principle, Liskov Substitution Principle, Interface Segregation Principle, Dependency Inversion Principle) are far more important than design patterns. Read Uncle Bob’s article Principles Of OOD

    Beware of dogma. There’s usually more than one way of doing things. The term “best practice” is overused. There are some good practices in software development, but beware someone telling you that something is the “best” way of doing something.

    No one has it all figured out. Some know more than others. Always try to be the worst member in the band. Read “The Passionate Programmer” by Chad Fowler.

    Watch Barbara Liskov’s talk “The Power of Abstractionhttp://www.infoq.com/presentatio

    There’s no such thing as perfect. You can always be better. “The perfect is the enemy of the good” – Voltaire.

    If you don’t design for scalability, your code won’t scale. If you don’t design for security, your code won’t be secure. Same applies for all    *-ilities.

    You are not your code. Criticism of your code isn’t a criticism of you.

    Remember, it’s a team sport. Great products are built by teams. Read the book “5 Dysfunctions of a Team” by Patrick Lencioni, or watch his talk about the book. It’s a really great book on how great teams operate.

    Don’t go dark. Share your unfinished work with others willingly. Read “Dynamics of Software Development” by Jim McCarthy

    Test your work. Try writing tests before code. Try TDD. Try BDD. Read “Working Effectively with Legacy Code” by Michael Feathers.

    Learn multiple paradigms. OOP, Functional, etc. Your OO code will improve after studying functional languages such as Haskell and Lisp.

    Watch OOPSLA 97 Keynote by Alan Kay, “The Computer Revolution Hasn’t Happened Yet”.

    Never stop learning. Read as many books as you can, but not only technical books. Read “Zen And The Art of Motorcycle Maintenance” by Robert M. Pirsig.

    Read “The Pragmatic Programmer” by Andy Hunt and Dave Thomas.

    Read “Code Complete 2” by Steve McConnell

    Read SICP (Structure and Interpretation of Computer Programs) by Harold Abelson, Gerald Jay Sussman, and Julie Sussman. Don’t just read it cover to cover. Follow along with a Scheme environment (e.g. Racket) and actually write some code.

    Don’t ask permission to refactor, test, document etc. It’s all part of “programming”. Don’t ask permission to do your job.

    Care about your work. Care about your customers. The code we write allows the users of our code to get their shit done, without our software getting in their way.

    Always ask “what problem am I trying to solve”?

    In general, stick to solving one problem at a time. When you spot other problems, note them and come back to them later.

    Be where you’re at. This is a life lesson that applies to software development. When you commit to doing something, focus on doing it. When your washing the dishes focus on washing the dishes – forget all the things that stressed you out that day. If you are spending time with your family, be there – turn off your phone, forget that tough problem you’ve been wrestling with. When you’re in a meeting, participate – focus on the conversation and forget about the work that’s piled up. Read “Zen Mind, Beginner’s Mind” by Shunryu Suzuki

    Single Responsibility Principle has broader applications than just to code.

    “Premature optimization is the root of all evil” – Donald Knuth. Start with a brute force algorithm until you find a reason to change.

    Ask “what’s the simplest thing that can possibly work?” Read “eXtreme Programming Explained” by Kent Beck. First version is supposedly more extreme than the second.

    Be OK with you. You will never know everything – that is impossible. Keep learning, but don’t get caught up on what you don’t know. Watch Kent Beck’s talk Ease at Work

    Be humble. Everyone is at different points of learning in their career. Help others on their path. Ask for help when you need it. Give back to the community. Watch Leon Gersing’s talk “Truth, Myth and Reality in Software Development

    It’s OK to be average  Read the article In Praise Of The Average Developer – Why the myth of the “10x” programmer is so destructive by Matt Asay. Matt Asay references Jacob Kaplan-Moss’s keynote at PyCon 2015.

    Multi-tasking is an illusion. Computers get away with it because they can context switch really fast (most of the time). Context switching for us mere mortals has a high cost. Do one thing at a time, and do it well.

    9 women can’t have a baby in a month. Read “The Mythical Man Month” by Fred Brooks.

    There is no spoon*. Just a reminder to lighten up a little bit. Have fun.   

    • This topic was modified 1 year, 2 months ago by  Greg Makowski.
    • This topic was modified 1 year, 2 months ago by  Greg Makowski.
Reply To: 42 lessons learned on good coding
Your information: