Seriously. That's it, just in a kind of special way.
I don't see myself as a good programmer. In my own eyes, I'm just an OK programmer, but I've spent a lot of time reading code from people that I do think are great programmers, and one thing I've noticed about most them is that they spend a lot of time and effort into being lazy, and this sounds extremely counter intuitive.
There are a few different sides to this dice (which goes against my 1 step title, oops!). You can be lazy in the way you design things, or in the way you write code, or the way you solve problems.
I've had a lot of projects that I worked on that I spent days just doing nothing with it. I would sit and work on other things while thinking about the project, working on it in the back of my mind, and every now and then, just lay on my bed and actively think about the project. I'd work at the concept and design the whole thing in my head, thinking about possible pitfalls or roadblocks. What would happen when this and what could cause that... So by the time I get to writing anything down, the projects is already completed in my head. I just need to document it and write the code. The actually writing the code part usually takes a few days from then on and things generally just work as intended.
I've had other projects where I'd get an idea and just start coding without really having completed the design in my head, and every time, I've gotten stuck at some point and have had to backtrack and redo a large portion of the program to work solve the problem I encountered, setting me back quite a bit time-wise. Every time this could have been prevented by just spending a day thinking about the project before starting it.
A great thing about spending that much time thinking about your projects is that it becomes easier to spot potential problems. You become faster at designing it in your head and after a few years, you can design things on the fly and avoid problems out of experience.
One of my goals in life is to sit around at home, without responsibility, play video games and watching TV. I like doing nothing, and being lazy, but here's the thing. That's not just going possible, I know that. So I came up with a plan. Work my ass off now so that by the time I'm 30, I have enough stowed away that I can retire and live off of the interest. Be the same in programming. Spend a lot of time initially doing things in a flexible and robust manner so that you don't need to later on. Make your code re-usable by making it as flexible as possible and creating a library of it. Create functions/methods if you need to do the same thing more than once. Create overloaded functions if you need to do the same thing but slightly different. Use classes when you need to group variables. Try to predict future uses of the things you create.
DiceSite tmpSite = new betking();
tmpSite.Login('username','password',123456)
tmpSite.Bet(0.0001,49.5,true)Is much eiser and faster to use than trying to remember how the login procedure at betking works, how to subscribe the signalR events, in which format the sent and received objects are, what the objects look like and what events to subscribe to.
Break down your big problems into smaller problems. Get the solution for the smaller problems and build them into a bigger solution. That's much easier and faster than trying to solve a big problem all in one go. This isn't always as feasible, but you can always simplify a problem in some manner. Start with the easiest solution you can think of, and iterate from there. Why write a 500 line algorithm when there's a 50 line one that does the same with the same performance?
A lot of the times, the simplest solution is the best, so by simplifying the problem, you inherently simplify the solution.
There's a famous internet quote from Bill Gates, which may or may not actually come from him:
I choose a lazy person to do a hard job. Because a lazy person will find an easy way to do it.
Programming is hard, but it's all about finding the easy way to do it.
Documenting what you do and adding comments to your code makes your life much easier. If you need to use a function that you wrote 3 years ago and don't have any idea how it works, an intellisense popup explaining the function and the basic layout of how it works, and the purpose of each parameter and overloaded parameter saves you a lot of time. At my current job, I had to take over a lot of projects that was just sitting idle because no-one else could work on them. With most of them, I spent more time reverse engineering what has been done so I can figure out what needs to be done. Several times I've just scrapped the whole thing and started from scratch because it would have taken me longer to figure it all out and start working in a similar way to complete the project. Save yourself from this by commenting on what you, why you did in that way and how it is and should be used. When doing maintenance (and everyone does maintenance at some point), documentation isn't the buoy you throw out when someones overboard, it is the boat your sitting in.
In conclusion, it's not about being lazy now, it's about working your ass off now so you can be lazy in a years time when you do something similar.
I know a lot of people are going to disagree with me, and that's OK. These are just my personal observations