21–30 of 45 posts
Start something from zero to profit getting to know all the steps to do so. You might not become the most technical programmer but you'll be one that knows how to deliver real value.
IMO what makes a great programmer is leverage and leadership. It doesn't really matter if you're a rockstar "10x" etc., what matters is how your work empowers others. Nobody is programming in a vacuum. In order to become great at that, you have to make enough mistakes that affect other people until you understand what helps and what hinders them. You have to realize that your code isn't just implementation but is hum…
> IMO what makes a great programmer is leverage and leadership. It doesn't really matter if you're a rockstar "10x" etc., what matters is how your work empowers others. Nobody is programming in a vacuum. Nah. There are those types of folks, but there are other folks who are clearly above the rest in terms of technical ability. See John Carmack, Sanfilippo (of Redis fame), 100s of others. Or heck even folks who deeply…
IMO what makes a great programmer is leverage and leadership. It doesn't really matter if you're a rockstar "10x" etc., what matters is how your work empowers others. Nobody is programming in a vacuum. In order to become great at that, you have to make enough mistakes that affect other people until you understand what helps and what hinders them. You have to realize that your code isn't just implementation but is hum…
Leadership and engineering are two different skills. They may coexist in one person. But great engineering is not always a great leader.
You learn go for that.
Sorry.
I think a great way to improve your codebase is to write unit tests, integration tests and by using languages with more types than say, JavaScript or PHP.
If the language has a lot of conventions for types, you can add satisfiability resolvers (SAT resolvers) and what kind of assumed safety/security comes with that.
Also, do capture the flag events online (e.g. picoCTF is a great start) which teaches you a lot about naive assumptions and programming mistakes and the reasons _why_ you should never use C++ for anything critical, and why memory ownership always fails when humans do not agree on conventions.
Earlier quoted context omitted.
> IMO what makes a great programmer is leverage and leadership. It doesn't really matter if you're a rockstar "10x" etc., what matters is how your work empowers others. Nobody is programming in a vacuum. Nah. There are those types of folks, but there are other folks who are clearly above the rest in terms of technical ability. See John Carmack, Sanfilippo (of Redis fame), 100s of others. Or heck even folks who deeply…
and why have you heard of them?
Sheer technical ability alone is not enough to be a great programmer. If you don't know how to properly communicate with others you are useless to your employer.
Earlier quoted context omitted.
What is your opinion of code coverage requirements now? I have been in a "phase" of seeing them as "code quality theatre". Considering that a function which takes a single 8-bit integer as an argument already has 256 unique inputs, and may bug only on 1-2 values, 100% statement coverage can be very misleading. A typical function has billions or trillions of unique inputs and 100% statement coverage could be very near…
Coverage is necessary but not sufficient, your tests also need to be good and test the right things. What's your proposed alternative - that we don't even try because our tests aren't guaranteed to be perfect?
For even a fairly trivial piece of code, the search space for bugs can be vast or even infinite. Writing unit tests to find bugs within that space is like throwing darts at an infinitely large wall and trying to hit an unknown number of invisible targets. You can only write tests for the potential bugs you anticipate - if you could anticipate a bug, you wouldn't write it, right? You end up with dozens or hundreds of tests that probably never failed, except when you have to change something. Such was my experience when I tried to maintain high code coverage. When I switched to writing assertions and acceptance tests, my rate of bug reports did not change, and I was more agile.
Earlier quoted context omitted.
> IMO what makes a great programmer is leverage and leadership. It doesn't really matter if you're a rockstar "10x" etc., what matters is how your work empowers others. Nobody is programming in a vacuum. Nah. There are those types of folks, but there are other folks who are clearly above the rest in terms of technical ability. See John Carmack, Sanfilippo (of Redis fame), 100s of others. Or heck even folks who deeply…
and why have you heard of them?
As I've worked with more senior engineers who have done this over and over again, I've noticed that the raw programming part isn't any different. I still know all the same things. But they have the most valuable ideas from experience. Their foresight to lean towards a specific implementation because they've seen where this plan falls short in the past ends up being a massive time and money saver.
Dealing with tricky problems has provided the largest growth for me. I worked at a scrappy startup where I wrote a ton of CRUD endpoints and got to do something interesting here and there. You don't learn anything new when you write the same code over and over with some basic stuff in place. I've found that I've learned the most from problems that are intimidating at first.
It's honestly comforting to know I can write similar code to more experienced engineers but I'm lacking their foresight and experience.
Start something from zero to profit getting to know all the steps to do so. You might not become the most technical programmer but you'll be one that knows how to deliver real value.
Sorry to be blunt, but how does knowing how to sell software make you good at writing it? What’s the end goal of the act of writing code supposed to be?