What one tip changed your coding skills forever?
In this post, I wrote only this paragraph. All the texts came from a Twitter conversation that I believe worth saving. I kept the writing style as it was, and even kept some ideas that I disagree with. It all started by this:
Problem solving
- Focus on the problem at hand instead of thinking about fundamentals.
- I used to code many features and worry about more features that I could code but no one saw them before (and no one asked). I was losing time (and money), so now I decide, first of all, to focus on understanding what is needed before to write a single line of code
- Think about your future code. Don’t just write! write! write! Because if you don’t think enough, at some point you may need to rewrite a lot of code.
- Tell yourself what your code is going to do, precisely, in each and every step, as you would a story. And when it all makes sense, start coding, piece by piece.
- Solve the problem first and then write the code
- Imagine you’ll be teaching someone else what you’re learning.
- Visualization of problems and algorithms.
Software Craftsmanship principles are recommendations and not rules, feel free to ignore them, just know what you are violating and why.
Raz Shoty
Write it down
- Draw or write it in a white paper. Analyze. Then code.
- Before start writing code, plan your logic mentally or on paper.
- Write the problem you’re trying to solve. Type up the steps to solve it. Make these your comments. Now fill in the code between the comments. This way you never lose sight of the big picture, and you always know what each code-block/function is doing.
- Stop that greedy mind from thinking in code; instead, tell it to think in pseudo-code first.
- Thinking and writing down complex logic on paper first.
- Use plain white paper to draw out your thoughts. Go offline.
If you’re feeling stuck, write it out.
Sleep on it
- Move on and come back to that problem later. Don’t be stuck on that problem for ages, walk away or do something else and when you come back to it, the problem is easily resolved.
- If I get stuck on something for too long. And feel like it is a mission impossible, and I sleep on it.
- If you’re staring the problem down too long, walk away and come back to it later. Often it will be an easier or better solution you come back with.
- It’s ok to not know and it’s also okay to learn it on Monday. You can take days off.
- taking a walk whenever stuck on an issue for far too long.
- When you are stuck bad take a break get back to code with a fresh mind!
- If you’re stuck, leave it and try after some time. Always work for me.
Taking some fresh air, light music or just walking makes your mind fresh! And when you come back you get new thoughts/ideas. This way you don’t waste much of your time!
Break down
- Break down a big piece of code into small functions.
- Understand the logic behind it, before moving onto more complex concept’s
- To break the problem into small bits, write it out and tackle them one by one. It was revolutionary bro.
- Translation of logical thinking into code. Breaking that logic down code by code. First being clear what needs to be achieved when implementing the steps using code.
- Insist on pseudo-code and tackle your program in small bits.
- Every complex and difficult problem is just a lot of small and easy problems in a row.
- Try breaking a big problem into smaller parts and begin from there.
- Thinking backward and analyzing projects into small factors.
- Think twice, Code once.
My father once told me: “We are developers not because we love computers and hard work, we are developers because we are lazy as fuck so have that always in mind”
Joel Spriggs
Relax
- Relax and breathe.
- There is a limit to optimization.
- Slow down, don’t panic about it.
- There is no such thing as perfection, and that’s ok.
- Don’t try to paint one good painting, try painting 100 decent paintings.
- Its OK if you don’t understand a thing… It’s part of the process.
- Just build what you love. It took a lot of stress off of me when I’m developing, which improves my code a ton
- Experienced programmers also don’t know the answers, we all are trying to figure out something just at different levels. so not to know what you’re doing is the constant, not the exception and that is more than ok.
- Yes! It’s ok to dislike a language for its syntax! Some are just overly convoluted and poorly designed, while some are just…highly optimized. Oh, and PHP makes my eyes water.
- just keeping on coding and let the creativity and mistakes happen.
- Nobody writes good code on the first try. Write bad code, they improve it. It‘s very similar to writing.
Go for it, what’s the worst thing that can happen, it not work, it doesn’t work now!” I guess kind of like, “fail often” mentality. Once you’re not afraid to break it…
Learn
- Learning all the time.
- Focus on mastering ONE language, instead of trying to learn everything.
- Taking time to study the documentation of the language or framework I want to use before starting at all.
- Drilling the basics of new languages and frameworks, or ones I’m coming back to. Lots of people are pointing out you can always use Google or docs, and that strategy served me for years. But really KNOWING syntax etc. saves lots of time in coding, reading code, and debugging.
- Learn the basics of JavaScript then continue to libraries!
- It is more important to know what the language, framework, etc. can do, you can always look up syntax.
- The best way to learn something is to teach it.
- Learn data structures, algorithms, design patterns, and software architecture.
- Just learn what you need to know about the requirements. You don’t need to know everything. If you want to peel back a layer and understand how it works you can, but it’s not required to get the job done.
The one tip that changed my coding skills forever is, teaching whatever a I learned.
Socialising:
- Don’t hesitate to ask questions, when you stuck with something. Forums/DMs, but be humble and polite.
- Explain your code to someone else.
- Start Competitive Programming.
- Don’t be afraid to use what others have written.
- Some problems can be solved by talking to people instead of writing a script.
- Try to leverage the tools you already know first then seek help.
- Pairing with senior developers.
- Brainstorming with errors & digging in packages source code.
Asking for help – realizing you don’t know everything and you never will either, and that’s ok.
Practice:
- Doing it, not watching it.
- With each iteration, you’ll get better.
- Take what you’ve just learned and built your own stuff.
- Find a programming language, learn and build… then keep repeating and practicing.
- this one “You will not become an expert overnight, keep practising, keep coding, you’ll get there”
- Build, apply, get your hands dirty with trying different possibilities
- Understand how the code structure works, then put it to the test, by practicing and making mistakes.
- You need to practice.
- Practice makes perfect.
- Try to solve one problem daily in StackOverflow.
- Solve one problem every day in CodeWars, thank me later.
- That one tip for me was/is “you learn more by building projects”.
- Practice practice…
- Understanding the fact that only by building stuff will I be able to retain what I learned from coding tutorials and courses… that’s the greatest for me.
- Do not stop, always learn, and go forward. Coding skills will inject by “Autowiring”.
- Not to skim the basics and really understand the foundations so that you can compound new knowledge on top of that.
- Spending time on fundamentals rather than rushing through them. Focusing on an area or stack.
- Learn and understand the BASICS well before anything.
- Start creating! and master the basic of HTML, CSS, and JS
Always go for things you find very difficult. It helped me learn a lot. A lot of times I failed but it did give me invaluable experience.
Memorising
- Stop trying to memorize everything.
- Understand the code instead of memorizing…there are many ways to do the same thing once you get the concepts right
- Don’t memorize code, instead understand the logic.
- Don’t occupy your mind with unnecessary things to remember, keep them on a book or note them somewhere and use your mind of Innovation and Making things on Book work efficiently.
- You don’t have to remember/memorize those syntaxes and functions. The knowledge that they exist is simply enough. Even in ICPC competitions, programmers are allowed a pile of reference materials and language docs.
- Take tutorials only to solve problems that arise when developing those projects.
- Stop trying to memorize the syntax and just work on projects
Don’t waste time learning stuff you don’t need to know
Testing & Debugging
- Code, question it, Code, Read more code, understand the problem.
- Get a crappy version just working first. Make it pretty and organize later.
- Write Tests.
- If you are really stuck, step through code one line at a time. Debugging works!
- Use IDE debugging features. Saves so much time.
- TDD completely changed my way of coding. I started enjoying coding after following TDD methodology.
- Learning to write unit and integration tests properly.
- For error tracking do not take the help of debugger or console(javascript). View code and ask your self what I did wrong. Initially, it takes time and frustrates you, after a few days you see improvement in your thinking.
- This might sound basic, but learning to trace/log and step through code to figure out how it’s working at specific moments really transcended my tolerance for complexity.
- When I first learned to use a debugger instead of awkwardly sprinkled print statements.
- Code -> Test -> Refine -> Tweak
Learning about minimal happy path. It’s easy to fall deep into develeping features that are nice-to-have but not essential to make app functional. Forcing yourself to focus on basics, not fancy additionals is one of the most important things to learn.
Clean code
- Write clean code and just have fun with it.
- Make it read like you’re reading a story.
- The code is read more often than written.
- The code is intended to be read by humans, so write code with the reader in mind.
- Single Responsibility principle: A unit should have one reason to change.
- Functional programming i.e. cut your code in functions even if you don’t use it multiple times. It will make it easier to read and maintain.
- Single Responsibility Principle – SRP
- Use Map Filter Reduce functions, instead of using loops to transform arrays. It’s more compact and sometimes more performant
- And also follow rules, even just your own. Be consistent. Try to do the best you can. Don’t give up. Keep learning and practice.
- Use “Wishful thinking”: Imagine the interface then do the implementation. It helps you structure consistent layers of abstraction.
- It’s okay to write dirty code. Once it works, make it clean.
- Refactoring: Make the change easy, then make the easy change.
- Never choose an inefficient shortcut way to save a few minutes. Every time you code, give your best!
- Separation of concerns. Keep your functions and classes as light and as simple as possible.
- It’s not a tip, it’s a book: Clean Code: A Handbook of Agile Software Craftsmanship.
- Don’t write long functions.
- One function 20-30 lines make life easy!
The biggest one for me was when I learned that you should focus on making your code self-documenting instead of writing comments for everything. You should, of course, still, write comments for complex bits of code. But accurate function/variable names provide context
Clean code: KISS
- Keeping simple, without over-engineering the problems.
- Don’t overcomplicate things. Sometimes it is better to write more lines and keep things clean.
- Don’t try to be smart with your code – make it as simple as possible.
- Don’t overcomplicate, a function should only have one task, stuffing more will make it brittle.
- KISS – keep it simple stupid principle, it always helps to know what is the best solution.
Documentation: Writing it
- Good docs -> Good code
- Do not doc your code. Code your doc!
- Understated but document your code properly. Make it so simple that anyone can get an idea of what’s going on.
Documentation: Reading it
- RTFM!!! Learning to correctly read docs, and to know what to look for, seriously upped my coding game.
- Spend some time on the documentation before starting a new language/framework.
- More documentation studying… Helps to know what you are doing in the first place.
- Reading documentation and self-documenting what I learn/do change the game for me
- Always read the documentation before starting a new framework, language, etc.
- Using documentation more, rather than Stackoverflow.
If you love it, why aren’t you doing it?
Google it
- Learning to really use google search terms = I can get virtually anything I want.
- Know how to google stuff.
- Don’t try to explain to Google, what went wrong. Just copy-paste error message.
- When I don’t find straight answers on google. I youtube. There is always 1 video with the answer u looking for.
- Don’t go after syntax, learn to solve the programming problems. Google is here for us to keep syntax on the.
- I think proper googling skills should be structured into coding courses.
- Copy and paste an error message on Google, It has helped a lot.
- Google Search is a part of programming!
- Less googling….
Some more
- No magic, only logic.
- Having a keyboard with numeric keypad, turn off num lock permanently, use the arrows there. Now I have arrows, home, end, page up/down quickly available, never looking the keyboard again to find any of those or raising the hand to reach it while navigating code.
- The difference between maker time and manager time. The understanding that programming is about holding a large-sized context inside your head for hours together. You are better off sitting for long stretches rather than follow an 8-hour window. We are by design always risk bound.
- When I was in 8th grade and was mad at how someone could make a syntax such as that of C, my brother told me: it’s not science that will start making sense intuitively, the syntax comes from some people’s personal biases and you have to live with it. And then It all made sense!
- Don’t look for a single tip to improve your coding skills.
Conclusion:
That there is no one tip to change your coding skills forever. And that paradoxes exist.
Other post about the same subject:
In this summary, I list some of the things that have helped me in my career. It reads fast, but applying them well can take a lifetime. I have been developing applications for almost 15 years, and still, sometimes, I have to stop and think in the essential parts of this profession.
Kesk: 40 Tips that will change your coding skills forever