One more characteristic: fearlessness. You have to be able to not only start, but commit to completing, a project even tho' you've no idea how to do it. You have to have that faith that you are smart enough to learn on the hoof, and you have to have the courage when you realize that you've written a ton of code already, when you realize you're heading down a dead end, to just delete it all.
I couldn't agree more, both about fearlessness and about deletion. The only thing worse than deleting a ton of code is not deleting it. Without ruthlessness there is no containing complexity. How many software projects are run this way though?
Courage is far better than fearlessness. Fearlessness means complete lack of caution, since nothing is feared. Plunge forward without any thought of safety.
Courage, on the other hand, means paying attention to the dangers and going forward whenever it's not a mistake.
Having said that, fearlessness can be the correct attitude when dealing with situations that are extremely risky from the start, such as startups.
I've actually worked on a project that had the owners approached me at the start, I would have told them it was impossible due to various concerns. It turned out to be massively successful and they created a new niche, but only by rushing head-first into it and refusing to stop.
fearlessness - come to think of it, Git makes developer fearless while deleting current version code and put some new twist to it. cause you can go back to it whenever you want it.
It's not the physical act of deletion that matters. It's the psychological act of abandoning something you've invested time and effort in when you realize it was wrong, and not looking back.
The "de la" means "some" or "some of," while "la" alone just means "the".
"Folie" (folly) is an amorphous, uncounted quantity, like water or sand. War is a one-of-a-kind entity, like "Peltier effect." So you speak of "some water" but "the Peltier effect."
When thirsty, you could say that "I want to drink the water," but unless there was an antecedent already set up in the conversation, it would sound a bit silly.
Interesting. I know the definitional difference between de and la and I know that de applies to indefinite things and so on. But the rules don't help here because to me (an English speaker with rudimentary French) la folie and la guerre aren't in different categories of definiteness to begin with. In English, war in general is just war, no different from madness in general being just madness. Thus I would never have constructed the sentence that way, and even after you explain it it still seems strange.
Once you tell me that la guerre is definite and la folie amorphous, then sure, I'd know to use the articles that way. But I would never have guessed this. It seems you have to know how the nouns feel to a French speaker; you can't simply compute the right answer from the concepts.
It seems as though the programming field is in a bit of a bind because, odd though it might seem, it has been difficult to be empirical in our approach to our field. The programming domain is very complex, so there are considerable difficulties in implementing empirical approaches. Proprietary development often entails a degree of secrecy, so a lot of data is not available to be shared. There is even debate along the lines of what is valuable to measure, or what can even be measured. One is reminded of many social sciences and psychology, or even medicine prior to the scientific revolution.
What is holding programming back from the degree of empiricism found in a field like mechanical engineering? Is it that it's hard to fund or even structure meaningful experiments? Should someone be developing non-ferromagnetic monitor/keyboard sets so that we can study programmers of different levels of demonstrated ability with their heads stuck inside MRI machines? (Such research has been done with piano virtuosos playing on electronic keyboards and rappers.)
Another thing I'd note, is that a lot of debate about programming is word salad full of reasons why you can't say X or Y. There seems to be a lot of the Epistemic Viciousness that exists in martial arts schools.
I would add that as soon as anything in programming is well understood or becomes measureable, it is almost immediately automated as either a supporting tool or software library. The humans are necessarily just doing the stuff that hasn't been turned into code yet.
Not everything that counts can be counted and not everything that can be counted counts. - Albert Einstein
I don't think programming is necessarily unique in this regard. As with any other profession, there are things that can be measured, and things that you just have to trust your gut on.
Assuming a "great programmer" is one that writes good quality code, then I don't think tools are necessarily about making you a great programmer, I think they're more about making you a faster and happier programmer. I would probably write the exact same code in nodepad as I would in vim, but I could probably write it in significantly less time in vim, and I would be much happier and less frustrated along the way.
happy programmer and better programmer do have high correlation though -- as better programmers tend to have more leverage on their environment to make themselves happier.
True, but the issue is that what defines happy is up to the individual programmer and articles that try to define it just lead to generating debate, ex. vi vs. emacs.
The best programmers that I’ve known put people first. They’ve realized that the software that they’re writing is for people, even if it’s just the back end of a complicated system or a protocol that no one but other developers will ever use. They write documentation because it’s important. They help people use their code. They’re willing to work extra and deal with a bit more complexity to give the people using their software the right solution.
I always get a bit irritated when people make the "people first" argument. It's not that I disagree with putting people first. It's just that "putting people first" always seems to mean "being a good cog in the machine".
There's more to putting people first than writing documentation and explaining your code to other people. Those are important, but they mean putting the task first, not the people. To put people first, you have to do things like: listen to others, empathize with them, use tact, compromise, and occasionally do something impractical for no other reason than to help work suck a bit less.
On the other hand, you can always tell software that was written (and/or bought) by someone who knew they'd never have to use it themselves. It's why most corporate software is so bad: it's written by someone who really couldn't care less about General Ledgers, and it's bought by the CFO who has staff to actually operate it.
While I agree with the main points of the post, I'd like to defend learning proper tools.
Even if a good text editor like vi won't make you a great programmer, it most definately will make you a better programmer!
First, you'll be more effective and thus achieve more. You can squeeze more refactoring and trying out different things when you are more efficient. This could lead you becoming great at some point.
Second, it's about your mindset. Programming is about automatizing and a great programmer should aim for the highest achievable level of automation. Why should your tooling be left out of the equation? With proper tools you can automate more.
If a developer has more then 1 year active developing to do, learning e.g. a good editor will pay off.
Having used xemacs for quite a while now, I'm finding visual studio to be more effective for following convoluted code. But maybe that's how the code got convoluted in the first place. Perhaps there's something to be said for less capable editors.
My brother took a Python class his Senior year of high school
The best I got out of high school back in the early 90's was an "Intro to Computer Programming" using Turing[1], of all things on a Macintosh Classic. Of course we didn't have the internet either back then, but I digress.
You guys are so lucky to be growing up post internet. :)
He took it at a college as part of a program where kids got to take a few college courses while still in high school. We didn't have any computer science while I was in high school, and my family didn't own a computer until halfway through my sophomore year, so a big chunk of my high school programming was BASIC and assembly on TI calculators.
While tools may not make a great programmer, tools do make a great programmer more effective. In fact, I'd say passion (I'd prefer a different word, but need something stronger than strong preference) for tools is a trait of great programmers. And sure, the desire to optimize one's toolset comes from deeper motivations, but I think a better programmer is, among many other things, one who never passes up on chances to improve productivity through better tools.
And sure, there isn't going to be a single set of tools for every programmer and every workflow, but good tools and a thorough understanding of them are something I would expect from a great programmer. I agree with most of the author's points, and don't want to at all suggest that becoming a vim wizard will on its own make you a great developer, I guess I'd hate to discourage anyone from seeking "text editor zen".
I'll throw in my favorite under-rated characteristic of good programmers: the ability to throw away code you've worked hard on. Sometimes code that is well written, tested, and documented just isn't needed anymore or doesn't fit with new changes to an architecture. The pros throw it out without a second thought. Many programmers find it hard to let go and it causes serious bloat to a code base.
Communication - if you can't talk* about solutions and translate them into code that others can work with, learn from, maintain, etc. then whatever else you have doesn't matter. Your impact will be limited to that you can directly touch. You will never be great.
* "talk" most of the time means "listen and understand".
The way pleasure factors into great software development is super interesting to me. I don't think you can be a great programmer (and I have to say I have no clue where I'll fit on the scales of developer skills) without loving what you do, but I have known programmers who love it and weren't necessarily all that great at it when I knew them, because of how early things were in their career. Who knows if they'll be amazing at 30 or 45 or 80, though?
Somebody who delivers sh*t that works, on time and under budget. The code is robust and can be maintained, with extra points and gratitude if it's well-documented. Oh, and said code both scratches an itch and solves an important customer problem.
