So you’ve already managed to achieve your first programming goals, maybe developed an example application for two. Great! However, it was a bit slo...
For further actions, you may consider blocking this person and/or reporting abuse
You'll get a huge burst of speed when you learn how to use an IDE and a debugger. This allows you to read source code and follow the call stack. Once you've mastered these tools you rarely need to use documentation.
I generally avoid IDEs wherever possible these days. They have their place for solving difficult problems after code has been written but they generally just get in the way while writing code and I find myself shaking my fist in the air at the devs of every IDE I've ever used for doing dumb things.
For example, I'll start typing the first character of a new line of code and the IDE will decide to live syntax check right then, hang the whole IDE for a solid 3 seconds, and then kindly let me know that there is an error in the syntax. Well, duh - I typed the first character of a new line of code!
I generally just use a plain old text editor (without syntax checking, autocompletion, etc.) and command-line tools and only fire up an IDE if I absolutely have to. So whenever I do fire up an IDE, all of my pet peeves with IDEs bubble to the surface again from long startup times, annoying project management tools, unnecessarily large amounts of RAM usage, massive CPU spikes, insanely long compile times, a window the size of a postage stamp to write code in, broken builds/projects requiring wasted hours to figure out which cache has to be manually deleted, IDE crashes and restarts, etc. The list is pretty much endless and some of those problems are exaggerated a bit but IDEs are mostly broken by design. I always breathe a sigh of relief and my stress levels drop when I can close out an IDE and go back to my regular workflow.
However, I've been developing software for a really long time. After writing software for many years, the fancy stuff stops being useful and starts getting in the way. A reasonable comparison is training wheels on a bicycle. Eventually, a person doesn't need them and the training wheels will even get in the way of riding the bike as it was intended.
My text editor of choice and the one I'm most efficient in when writing software and documentation is Crimson Editor, which was last updated in 2004. It's most definitely not for everyone. I'll occasionally fire up Notepad++ as well but even Notepad++ does obnoxious things that drive me nuts such as "forgetting how to syntax highlight and suddenly decide that the entire file is a comment" every so often.
Which tech stack do you use? Sounds like C++ or COBOL. I've been programming for a couple decades too and stopped complaining about IDEs around 2012. Mine are as fast as a plain Notepad when it comes to the typing responsiveness and 1,000x faster when it comes to the actual development.
I love this post very much. After many years of software development, the day it settled in me that simplicity is the best approach to problem solving, my career transformed for the best. I became less worried, had less sleepless nights and developed a better lifestyle.
Any fool can write code that a computer can understand. Good programmers write code that humans can understand.
— Martin Fowler
We don’t have to say yes to every project. (I wish I knew this earlier in my career). Although this may be different based on company/team size. Mental health is very necessary for optimal learning. When burnout begins, learning stops.
Speed is good, Efficiency is better
Thanks a lot for your comment!
Install a snippets extension to your ide. Learn ALL the keyboard shortcuts for your ide. Learn to touch type. Use a linter to format code and pick up poor practices. Write code in a consistent manner so that you and your peers recognise the code patterns.
Those are good tips as well:)
IDE? ;)
https://www.youtube.com/watch?v=9n1dtmzqnCU&t=2s
I think the point is not so much at being fast, not even about being efficient, but about being effective ... you can implement a solution super quickly, but if it's not the solution anyone wanted or needed then I'd argue your actual speed was zero ... :)
On the other hand, "fast" is probably easier to quantify (LoC or whatever) than "effective".
Oh, that's another big topic to cover. There are people many hours thinking and testing what the users would use, and pay for—product designer, etc. You can easily burn a lot of time and money building something nobody care about.
And I'm sure that that happens all too often :)
FTFY.
Third-party libraries are pure technical debt. Each dependency creates an exponential increase in difficulty to upgrade those libraries later on without breaking the application. Third-party libraries are necessary for exceptionally difficult topics that people usually get wrong (e.g. cryptography) or would take an inordinate amount of time to implement correctly (e.g. image processing). But developers purchase ALL of the technical debt of that third-party library or software when using it. For example, if someone makes an Electron app, they implicitly purchase all of the technical debt of developing a web browser from feature development to security issues whether or not they like that concept.
Here's a good rule of thumb is to evaluate whether to create a library from scratch vs. using an existing library: If a sufficient library with a stable API already exists, it would take more than a month to create an equivalent solution, there's no particular business reason for creating a first-party library, and the additional technical debt is acceptable to take on, then the occasional third-party library is probably fine to use.
Thanks for your comment and pointing out the typos!
True! Fixing bugs that shouldn't be there doesn't let you focus on developing new stuff. I touched this topic in another article: What’s the point of unit tests?
There is one aspect that can be overshadowed when trying to be "fast".
It's empowering others to move fast as well. It's one thing to be a 10x developer, it's another to work in such a way to help empower others so you become a multiplier.
Some things inherently will help you increase your own speed, but spreading out those gains is how you can really impact.
Plus who doesn't like working on stuff that is inherently easy to work with?
Very good point! Actually I should write a continuation to this post with the focus on team-productivity, not individual one.
This is a solid post, thanks!
Thanks a lot!