11–20 of 116 posts
I always read this... What exactly is a unit test? What parts of my software should be tested? What are some examples of good unit tests and the code that is tested?
In my opinion, "be humble" isn't a winning strategy. Don't be so arrogant that you stop improving or fail to understand mistakes, but by all means don't be humble. Be proud of who you are and the work you've done. You work in an industry where 90% of people don't understand what you do. Chances are your own boss won't understand the actual value you're providing. So don't be humble. "There's always someone better tha…
I think it interacts well with the concept of “strong opinions weakly held”. Have a strong opinion that you've built a great thing, but hold it weakly so that in the face of clear arguments or evidence that it is in fact not great, or that another solution is better, you can admit it and adjust. This, to me, is the right balance of confidence and humility---in programming, as in life.
1. Identify what it means to be good
2. Work endlessly towards that aim
3. Deliberately practice
4. Decide to refine strengths or squash weaknesses. Do this as frequently as possible. Make sure you have an accurate assessment of what your strengths and weaknesses are. (5) and (6) can help with this.
5. Consult the advice of those more experienced. As frequently as possible
6. Allow your work to be publicly scrutinized. Do not work privately, the feedback loop should be as tight as possible to inform (1)
7. Repeat (1) - (6) as frequently as possible
Do that and you will become better. Guaranteed. Note, this won't necessarily make you the best. However, it will make you better. Continue this process until you're as good as you desire. There, of course, are diminishing returns after a while.
In my opinion, "be humble" isn't a winning strategy. Don't be so arrogant that you stop improving or fail to understand mistakes, but by all means don't be humble. Be proud of who you are and the work you've done. You work in an industry where 90% of people don't understand what you do. Chances are your own boss won't understand the actual value you're providing. So don't be humble. "There's always someone better tha…
I think that's crossing the wires of humility and confidence. You can be confident but humble. Confidence is your ability to come up with solutions and feel like they are the right solutions, and that they are good or excellent solutions. Humility is your ability to come up with solutions and realize that (1) they might not be the _absolute best_ solutions, (2) some solutions that look like they're better are actuall…
So many people miss this, unfortunately.
Shocking to me that there are so many articles on this. The strategy to becoming a good programmer is the same strategy to become good at anything else. 1. Identify what it means to be good 2. Work endlessly towards that aim 3. Deliberately practice 4. Decide to refine strengths or squash weaknesses. Do this as frequently as possible. Make sure you have an accurate assessment of what your strengths and weaknesses are…
Mostly agree with that with the exception of learning new things. Sometimes it helps to be dogmatic about things if your goal is to learn something new.
A prime example is TDD. When my goal is to build a working piece of software, I tend to do TDD for some parts and write tests post facto (or not at all) for other parts. When learning TDD it helped to force myself to be dogmatic.
Similarly, if you're learning functional programming in a language that isn't strictly pure, its helpful to be dogmatic about your approach and force yourself to do things the functional way, while in the real world introducing limited impurities may be better.
> Nobody tells this to people who are beginners, I wish someone told me. All of us who do creative work, we get into it because we have good taste. But there is this gap. For the first couple years you make stuff, it’s just not that good. It’s trying to be good, it has potential, but it’s not. But your taste, the thing that got you into the game, is still killer. And your taste is why your work disappoints you. A lot of people never get past this phase, they quit. Most people I know who do interesting, creative work went through years of this. We know our work doesn’t have this special thing that we want it to have. We all go through this. And if you are just starting out or you are still in this phase, you gotta know its normal and the most important thing you can do is do a lot of work. Put yourself on a deadline so that every week you will finish one story. It is only by going through a volume of work that you will close that gap, and your work will be as good as your ambitions. And I took longer to figure out how to do this than anyone I’ve ever met. It’s gonna take awhile. It’s normal to take awhile. You’ve just gotta fight your way through.
That is, code a lot of stuff. And, while doing so, pay attention to how you feel. Sometimes it'll be exhilarating, or you'll be proud of what you done. Other times, you'll be confused, or afraid, or pissed off about how something you wrote earlier is now unmaintainable or hard to make work. This is how you actually learn the insights behind all the dogmas, rules of thumbs, heuristics, good practices, etc. That's how you develop taste - that intuition which will help you write good code.
"Write unit tests, they could prove to be invaluable, especially when you introduce changes to your codebase." I always read this... What exactly is a unit test? What parts of my software should be tested? What are some examples of good unit tests and the code that is tested?
In my opinion, "be humble" isn't a winning strategy. Don't be so arrogant that you stop improving or fail to understand mistakes, but by all means don't be humble. Be proud of who you are and the work you've done. You work in an industry where 90% of people don't understand what you do. Chances are your own boss won't understand the actual value you're providing. So don't be humble. "There's always someone better tha…
I think that the "be humble" criterion makes sense because it is directly correlated to the awareness that there is no single right way to do something. Changing requirements can pull the rug from underneath you and turn a good idea into a bad idea.
Software engineering is a bit like economics; a lot of people think that they understand it, but in reality nobody does.
> I divide and conquer and get things done. I had the same insight after many years like the author - that every problem you do can be broken down into smaller problems, which can be worked independently and tested independently. Why it wasn't obvious to me early-on I have no idea. I guess I never developed the intuition to see the efficiency of the method. Did anyone else among you had the same experience?
You are essentially describing 'test driven development', and many of us have either been taught the methodology, or stumbled on to it.[1] [1] https://en.wikipedia.org/wiki/Test-driven_development