I always considered myself to be a "good" programmer. Been at it on and off for 20 years now. Have been building my own desktops for just as long.<p>That idealization lasted until I decided to tackle a massive software project on my own recently, and I'm feeling increasingly unconfident about my abilities.<p>The more example code I look at implementing, the more I realize just how spaghetti-like what-I-call-programming really is.<p>I have never had any formal programming education. I took a "Java for beginners" course in university once and dropped out after 2 weeks because everybody in the course seemed to already know everything about Java and I was entirely lost.<p>I am embarrassed to admit that I don't have the slightest idea what "object oriented" even means.<p>I have cracked open "Clean Code" recently and have made it half way through "The Pragmatic Programmer" a few years ago ... but can't even find that book anymore :S<p>Are those even good suggestions for someone like me?<p>How would you suggest to somebody who already thinks they're a good programmer to go about actually becoming a good programmer?<p>A bit about me...<p>- comfortable w/HTML+CSS 20 years go with a SAMS 24 hour book<p>- comfortable w/PHP 15 years ago with a PHP for Dummies book<p>- comfortable w/Javascript 15 years ago with the web<p>- comfortable w/Python 5 years ago through the web<p>- comfortable w/Node 2 years ago through the web<p>Thank you so much for reading this far. Really! I appreciate it!
The book that improved my code readability, composability and testability the most is composing software by Eric Elliot.
<a href="https://leanpub.com/composingsoftware" rel="nofollow">https://leanpub.com/composingsoftware</a><p>Trigger warning - it shows how to apply functional programming techniques using JavaScript, but the lessons apply to any language. I used to think functional programming was only relevant for grey beards in academic settings where lisp and Haskell were used, not the web apps I develop. I was completely wrong.<p>The biggest improvement I’ve observed is in testability - I used to dread writing tests because they were hard to write, create fixtures for and brittle. Now it’s fun to write tests and I usually write them before the function, adding rigor to its definition. Tests are easy to write because my functions do one thing, have no side effects, and the inputs and outputs are fully defined in the signature.
Some suggestions:<p>- Get specific on what you are trying to get better at (spaghetti-like code, what object oriented means, finish a programming book?<p>- Which do you want to get better at HTML, CSS, PHP, JS, Python, Node?<p>- How will you know if you're better?<p>- Figure out if you're motivated enough to do it yourself versus get an instructor<p>- Can your massive software project wait or do you need someone to pair with you and/or answer questions?<p>Answers:<p>- Simple answer: Lambda School (not affiliated)<p>- Medium answer: Buy a few intro to X programming language where X is something you know and work through all of them<p>- More complex answer is build a DIY course yourself for yourself based on the answers above
Hey there! As someone with just half the years of experience you have... I'm just gonna leave my one cent here :-)<p>Clean Code is an excellent book to start going in the direction of what I'd consider "good programmer", in the sense that a good programmer writes code for humans, not for computers!<p>My opinion of "good programming" is just exactly that, the code is easy to read, easy to glance and figure out at a high level what it is doing.<p>About OOP, there are a ton of opinions regarding that (I kinda dislike it...) so don't really fret about it, a good programmer writes code that humans can easily read, that human being future you also, since a week later we often have no clue what our code does and need to read it again anyways!<p>Something that I've been enjoying a lot lately is investing in my tools, which for me right now is learning to use neovim, and even thought I'm not using it professionally (I think I'll never will because that might convert it into "work" and suck all the fun out of it) it has made a huge difference in my side, projects, you know, the code that I'm actually excited about!<p>I sympathize with you since I didn't took formal programming courses and most of the felt like I was not good, or not up to par with other or whatever... seems like my engineering manager and the previous raises disagree with me! So, don't confuse impostor syndrome with "not good"<p>As a last thing, I recently came across a couple of articles here in HN regarding building useless stuff[0] and homebrew tools[1], and in doing so I've been finding the joy and fun I used to have back when I was just learning!<p>So bottom line, don't worry about being good and focus on having fun/enjoying what you do!<p>[0]<a href="https://news.ycombinator.com/item?id=27256867" rel="nofollow">https://news.ycombinator.com/item?id=27256867</a>
[1]<a href="https://news.ycombinator.com/item?id=27482397" rel="nofollow">https://news.ycombinator.com/item?id=27482397</a>
I have 4 simple advices for you:<p>1. Learn to write tests. You will increase your productivity, the fiability of your code and decouple things. Either you go into functionnal programing, either OOP. But write tests.<p>2. Read other people code. Pick a robust OSS and go through the code.<p>3. Work in a team, preferably with people better than you. But even juniors can challenge you during peer reviews. If they don't understand your code, maybe it's not clear enough. It will also force you to explain what you do, and thus, find where it could have been simpler.<p>4. Paper code before writing.
Usually I:
A. Paper code<p>B. Write functionnal tests<p>C. Write pseudo code<p>D. Write unit test<p>E. Write code<p>This way, I'm almost never struggle on bugs.
Your problem is common. It’s about how to organize your code.<p>You’re good enough to solve the problems you need solving but you’re not experimented enough to make the code organized.<p>Code that’s well organized is easy to read, reason about, and refactor.<p>I don’t think there are books about this, and there is no right answer to these kinds of problem.<p>My advice is that code organization should come from code growth. Spaghetti code is not that big a deal when it’s small, but you should realize when it becomes a problem a reprganize accordingly.<p>It usually is hard. You need to split your code conceptually, and choose your abstractions and how you group files together<p>What I try to do is split the code into layers on who’s working on what.<p>The node guy will own the basic layer. Then you’ll have the business logic guy who will build the api. Then the frontend guy, etc.<p>These people should be able to work together without stepping on the other guy’s toe.<p>That in my humble experience is a good driving principle. This will make you define clear boundaries. For instance, writing a sql query from within a UI event handler is clearly breaking that principle.
Nowhere in there do I see any reference to knowing about Version Control Software, such as GIT. Having a good handle on GIT allows you to take more risks, because you have a better set of options if they don't work out. That then gives you more freedom to refactor code.<p>As far as Object Oriented Programming, unless you're doing something as complex as a GUI builder, don't worry about making things object oriented if a simple record type will do the job.<p>It sounds like you're on the right track. Good luck!
A good programmer solves tough problems. A better programmer solves tougher problems. Practice solving really tough problems, be ambitious, and then work on something more challenging.<p>Don’t worry about what other people think of your code. That is mostly vanity. Good code executes quickly and reduces complexity.
It sounds like you need to learn how to write testable code. For that, I would suggest two books: Working Effectively With Legacy Code and Clean Architecture.