The "developer on fire" podcast closes out each episode by asking the guest to provide three tips for delivering more value.
Some that occur frequently are:
* Take care of yourself. Get enough sleep, exercise and healthy food. Have hobbies.
* Constantly learn new stuff
* Practice communication skills. Building stuff fast and well doesn't help if you're building the wrong thing, and you need communication skills to prevent that
* Think about the context that your program will run in (related to the reason above)
Any tips on how to do this? I don't often feel things for myself and it's even rarer to experience empathy at a level I can detect. I meditate to try to better understand and learn to detect my feelings, but haven't made much progress yet (I use Headspace).
I've been confronted with this question a couple of times even before I read the articles linked above and I always answered the same. Always felt like it's such an "obvious" answer since reading fiction puts you in the perspective of another person/character, so it's good empathy exercise. My personal experience confirms this as well, that when I want to shift my perspective to that of another, reading fiction helps.
(Emphasis on "personal" as, in this use case, YMMV.)
On this note... the books I've found most interesting over the last couple years are ones that expand my mind to a viewpoint or a perspective of another people group that is different than my own.
Two very different books but, Between the World and Me, and How to Get Filthy Rich in Rising Asia both made me think in ways I cant quite describe.
Its hard to empathise if your thoughts are elsewhere. When a situation requires/deserves empathy then be aware (mindful, if you like) of the locus of your thoughts and, when they wander, direct them back to the subject. Your meditation practice will definitely help there.
Consciously recognising when your empathy is needed is the hard part. All I can suggest is to try to recognise and avoid habitual distraction.
Me, personally, here's what i do. I screw up all the time. Odds are, you do too. Usually, it won't matter, like a mistyped password. Sometimes i mistype variable or function names, and the compiler helps me out. Sometimes my logic is wrong, and testing shows me what i've done. But no matter how hard i try, errors seem to leak out to code review, and sometimes even production.
Everybody struggles with this. I find it hugely embarrassing. Don't bother calling people out for making mistakes, if they're any good, they know they've made a mistake. Instead, give advice about how you avoid those kinds of errors. We've all been there. It sucks. Instead offer up some tricks or techniques for avoiding that kind of problem in the future. If it's really bad, a war story about how you really messed up bad can be calming.
The gist is, your coworker is probably feeling a lot of emotions. We've all felt those emotions, and it's going to be ok. Later, we'll have a post mortem and find a way so nobody can ever have that problem again (or make it harder). It sucks coworker had to be the one to break things in that way, but coworker is helping ever other person to come after them. Somebody was going to do that eventually, coworker just got unlucky.
Having pets and being a good pet owner really helps.
They can't speak. You have to empathize with them to have any relationship with them. In social situations you'll end up reading body language and worrying about other's feelings without even thinking about it due to pet practice.
I wish this worked for me; I have plenty of empathy for non-humans animals. But I still find it difficult to empathize and relate with other people. I'm trying to get better and imagine myself in the other person's shoes and it does work to an extent, but it just feels like my emotions for people are greatly muted compared to those I experience for other animals.
I frankly do not believe that instinctive empathy is always necessary. Instead, like another suggestion, read good fiction- but also read people's real stories. There's a documentary on the families affected by the Sandy Hook shooting- this was useful to me. There's lots of people writing about their lives in situations you'll never be able to be in. Read them when you can, try to understand them, take people at their word when they say they're experiencing things. Chances are, they don't really have a reason to fake or blow it up nearly as much as it may first seem, even if it seems irrational or incomprehensible at first. Humans are rarely totally without some context or reason to their perspective.
Note: I don't have empathy for myself very well, but my own behavior can tread bizarrely enough that I am forced to examine my own behavior in a way that can be explained to others reasonably. If you can explain others' behavior in this way that isn't condescending towards them, that takes all aspects into their behavior into account, you will come off as compassionate and empathetic regardless of how you feel in the situation. At least this has been my experience.
I'm an empathetic person and I find myself often trying to put myself in someone else's shoes to see how I would feel if I were them. Nope sure it that'd help you but there ya go.
Journal and go to counseling (it helps to understand your own view of the world first)
Raise kids. No joke. They can do some pretty stupid things, and keeping them out of danger and helping them grow has actually helped me understand and empathize with my team quite a bit.
Be generous with your life (from small things like hosting guests in your home, to traveling to help people survive and thrive in other countries). When you see what others are going through, you'll probably have a gut reaction. You should probably trust your gut.
Read books on leadership. It helps to learn how other good leaders coped with similar circumstances. -- and yeah, I just called you a good leader without meeting you. Just asking this question and being introspective indicates you're on the path to being a good leader.
Practicing empathy for yourself is really hard. It's why most developers suffer from imposter's syndrome. I go to therapy in order to help "practice".
Doing all the other self-care that OP mentioned is a good way to start moving in that direction. Be patient and kind to yourself. Once you've learned that, you actually start developing and being able to feel that way about others. It sounds a little hippie dippie, but once you have patience and you're at peace with yourself, you're much better at being able to accept the faults of others.
Empathy is both a cognitive and an emotional thing. Getting to know your own emotions is great and helps in understanding others, which can be achieved by meditation. But it's also necessary to think about other persons and the reason for their behaviour. Here, I think, literature and other narrative forms of culture helps us. Read good books!
I've struggled with this, but feel that I've made some headway in the past decade, so for what it's worth, here are my two cents (YMMV): I'd say start by conscious effort, and then eventually you can build intuition and 'empathy' in a more traditional sense (and your mirror neurons might even help you understand your own feelings better that way too, as seeing something in others might help you recognize those same things in yourself). Whenever you interact with a person, consciously ask yourself questions like 'how does this person feel?', 'how do they perceive me?', 'what are they trying to achieve?', 'what do they think I am trying to achieve?', 'in what context will they interpret the things I say?' and so on. Even if you won't have a lot of those answers, just making yourself aware that there is information there that you are missing is a valuable step in noticing it - and teaching yourself to care about that dimension of the human experience. Understanding what goes on inside a person is not unlike playing an imperfect knowledge game, e.g. reading someone's hand in poker - a combination of observation, prior knowledge, statistics and logic can help gain you insight into likely scenarios (e.g. "Aggressive behavior is often due to being stressed, or feeling threatened - this person is normally well-mannered, so they are likely under stress right now, so instead of snapping back at them, I could ask them if there's anything I could help with - assuming they normally trust me enough to confide in me"). And read books/blog posts about psychology and what motivates people (e.g. watch stuff like this, https://www.ted.com/talks/dan_gilbert_asks_why_are_we_happy (that book is recommended too) and read stuff like this https://youarenotsosmart.com/ ) - it'll help you think about a mind as something that follows rules and patterns, even if those patterns aren't always strictly logical, and hence it is something that can be understood. Eventually, all these things can combine to give you an intuition (a heuristic if you will) about what goes on emotionally inside others and yourself, and as this becomes a greater part of your world view, you'll also get more of a chance to feel a link between those feelings inside yourself and others (which is what I'd call empathy). I think some people, the "natural empathists" stumble on this by themselves; they've just developed this intuition without ever becoming aware of it - but for a person like myself, I needed to understand it consciously before my subconscious could really catch up and start to work on the domain. But it's totally a learnable skill like all others.
Focus on the problem and not the tools ceremony around it.
Don't follow the herd and the hype.
When given a problem, keep drilling the problem until it is absolutely clear to you and then only work on solution.
I often encounter situations where a day or two were spent creating a mess of classes and abstractions, yet the actual logic to solve the problem still hasn't materialised. A defense about "code quality" or "not wanting to write spaghetti code" is often made.
My recommendations for a problem you don't have a clear solution in mind for:
1) Hack some pseudo-code spaghetti together in a blank file until you think "you got it"
2) Write some theoretical test scenarios in another blank file (given state, steps, outcome) to verify that it's actually "solved". Discuss with a team member if possible.
3) then write out those functions from 1) inside the existing codebase
4) verify stuff is working
5) only then do abstractions / splitting up into multiple files
For a problem where the solution is already existing, but the implementation lacking (e.g. a refactoring)
1) design the new code (data structures, interfaces)
2) always propose to the team - no ninja-architecture/refactors
3) ensure the solution can be tested, document what should be tested
Suggesting that is all well and good, but surely the concern is that the process will inevitably end after 4), or even 1) since "it works" and there are other higher priorities?
That's a communication problem, I think. You should outline that something working is a prototype, not an end-product. That means it's not maintainable, hard to extend etc...
To convert from a prototype to an end-product, you need to do the other steps.
"A woodsman was once asked, 'What would you do if you had just five minutes to chop down a tree?' He answered, 'I would spend the first two and a half minutes sharpening my axe'.”
Proper understanding of the problem is extremely important. Great advice.
>keep drilling the problem until it is absolutely clear to you and then only work on solution.
My experience has taught me the exact opposite: no amount of Google Docs or whiteboarding meetings will tell you what the real problems are, you're only going to find them when you start implementing.
I got burned on my last project: we spent several weeks mostly talking and writing (English) about problems that turned out to be trivial, and got totally blindsided by problems that were not detectable until we actually connected to the firehose of incoming data (it's a streaming/analytical system) and then verified our work. There were lots of subtleties in the way a small portion of messages could be related over days and weeks. Nothing we would have been able to forsee with unit tests or manual inspection. We had to actually write the program to find out what would be hard about it.
I would guess ankurdhama was talking about the problem from the customer's perspective.
When you hear them say: "I need a modern site", don't start until you're clear why they want it. For example "My customers told me my site doesn't look very trustworthy" will lead to a different solution than "My site is too slow" or "My site doesn't work on mobile devices".
Once you know the customer's why, you are also better able to make decisions like "It's okay to lose 1% of the data in case of failure in order to have a simpler system", or "We only look at the results once a day anyway, so using batching is acceptable".
If you know multiple programming languages. Sometimes adjust for the toolset. Eg. Python or NodeJS for crawling websites. I always abstract it with an api. For eg. Try take a screenshot of a website in c# ( my most proficient language).
SOME tools do get you much faster to the end result with more options. Just make sure you tackle that problem with that programming language and try to abstract it away.
Edit: My solution for website as a screenshot, a c# wrapper for a nodejs api
This is going to depend on what one specifically means by "great", but I would caution against adopting this perspective too thoroughly or sincerely.
There is a lot to be gained by going along with the dominant groupthink on a topic, and there is a lot of risk involved in declining to do so. This is especially true as the groupthought picks up steam and gains powerful backers, who will be offended that little-old-you would dare to contradict someone of their high status.
The likelihood that your successes over the conventional/trendy method will be undeniably obvious is very low, especially when you consider that as larger interests and personalities invest in the groupthought, their PR machines will be working to discredit/counteract those who stand to imperil their investment. You will probably not get the punchy ending that you'd need to justify the burn you initiated by going your own way.
You could try to argue that the rest of the team is just trying to follow the zeitgeist instead of thinking about how to generate objective value, but this will hurt much more than just smiling and using the "Tech Flavor of the Week" on the project.
Team cohesion is more important for large-scale productivity than technical implementation details. It's easier to work around a buggy framework than it is to get people to cooperate and release their grudges.
If you want to be a "great programmer" in the sense that you have maximal self-satisfaction, then yeah, you should use whatever you think is best.
If you want to be a "great programmer" in the sense that you're a hot commodity on the market with a strong network full of people who want to give you money, you must recognize that your field of operation is not really computer code, but the delicate egos of the humans around you.
---
Along a less social track: the bigger the technology gets, the more likely that its kinks will get worked out and that it or something based on it will become a driving force in something that is objectively useful/valuable down the road, at which time having the investment in the platform makes it easier to adopt the better tech from both a technical (increased familiarity with tech-specific syntax and concepts) and personal perspective (don't have years of resistance that you've brainwashed into yourself, + accompanying reputation).
JavaScript is a good example of a technology that has been difficult to justify at a technical level in any case where it wasn't mandatory up until very recently. However, its widespread faddiness is now starting to cause actually useful new things to be JavaScript-first or JavaScript-based, even if they're doing that just so they can ride the hype wave themselves.
1. If at all possible start from something existing. It is entirely possible by the time you are done nothing remains of the existing. That's fine. To me, it's easier to tweak existing code than fill in an empty editor window. To some, an empty editor window is all opportunity, to me, it's analysis paralysis.
2. Always be ready to throw everything away. You perhaps will save a few choice lines but be ready for your first, sometimes even the second solution to suck badly. This is fine. Putting in more time to have an easier to maintain solution is always useful.
3. To continue from there, easier to maintain code is king. Unless you are writing something extremely time critical do not try to be clever. A little slower is okay (and yes, I am in the performance consultancy business) if it significantly decreases the maintenance burden. Clever hacks belong to toy projects and blog posts. The next person who maintains it will be stupid to the code -- even if it's yourself. That clever hack is now a nightmare to untangle. In short: always code under the assumption that you will need to understand this when the emergency phone kicks you out of bed after two hours of sleep in the middle of the night. The CTO of Cloudflare was woken to the news of Cloudbleed at 1:26am.
I have always been a bit confused about logging. On the one hand it's invaluable for debugging, but on the other it creates some unpleasant looking code. Not only that, sometimes, log statements introduce defects in code. I am not sure of the performance implications of logging. But I put logs anyway.
Setting aside the fact that your question is loaded ("littered" with incorrect error handling--OK):
1. Return something meaningful, not the bare error you received above.
2. If you do nothing but decorate the error, ignore coverage. Having decorated the error helps debug the full system when the error occurs.
3. If your error handling is more complex (remove temporary files, close handler, etc.), you might want to factor the cleanup into its own function and test it there.
Finally, your code is not really "littered." If you had exceptions, there would be no trace of the possible errors that might occur on the production system. Your coverage will be higher, but when the software will blow up in production, it will not matter then least.
I sometimes temporarily modify the program by for example misspelling a file name of a data base column name just to provoke an error that will execute the error handling code. Or changing a condition from == to != to cause an exception. Not ideal, but at least the new code is executed at least once, so I see that it executes as expected.
Creating tests for some of these cases would involve mocking things out, and then you have to make assumptions that may not hold anyway. That's why I like to see it execute in the real environment at least once.
>I sometimes temporarily modify the program by for example misspelling a file name of a data base column name just to provoke an error that will execute the error handling code.
Yes, a lot of things like that are possible. I remember in one client-server project I worked on, we unplugged the network cable from one PC (while the program was communicating between client and server), to see if we got the correct error message that we had written for that case. And did other stuff like that.
This was done in a project I handled, for the World Bank. I had a team of 9 motivated though young developers (first project for most of them). Near the end, before we sent the software to the client, a colleague was assigned to test the software - testing by a member external to the team, a slightly senior guy, ex-CITIL (a Citi IT subsidiary which had more mature software processes than we did then), though of course we did test the software ourselves a lot, first. I remember what happened:
We prepared the machines and software for the test. Called him over.
He said: I am going to sit down and destroy your software.
We said: Go ahead, please try.
And he tried to. But could not. He only found a few minor cosmetic defects.
Getting up after a few hours of rigorous testing, he said something like - I am happy with your work.
- Add value. Train yourself to only do things that add value. Value is loosely defined. It can be going the extra mile smashing that bug that everybody is complaining about. It can be whipping up a mind blowing demo to pull in that big customer. Nobody cares if you work 80 hours a week, but it's not adding any value. Get in the habit of working on things that bring value to others.
- More communicating, less coding. This is extremely important in teams and large organisations. Communicate to make sure nobody does double work. Communicate to have your ideas and opinions heard. Communicate to avoid doing pointless work. The list goes on. Communicate with your peers, your boss, your customers.
- Have healthy habits. Eat well, sleep well, exercise. When you're young you can pull off all nighters and eating pizza's all week. As you get older, you cannot.
- Be reliable. When you say you're going to do something, do it. Write reliable, well-tested code that works.
- Fail. Make mistakes. And learn from them. Don't be afraid to take on a challenge. You cannot expect to be great without having made mistakes. You'll make them once and hopefully never again.
- Follow up. When people send you e-mails and messages. Answer as fast as you can. Things move a whole lot more quickly when people don't wait on each other.
- Be on time. Nobody likes people who are late.
- Always learn. Try new things. If you don't like them, then at least you tried and learned something new. Keep exploring and reading.
+1 for value. Unless you are a sales channel, every job can be generalised to creating value.
"Value is loosely defined"
This is a really worthwhile thing to think about - not only creating value, but levering it up.
If you spend the time to work/find something out, demonstrate it to others. If you change someone else's code for the better, explain why.
Minimise the cost of organisational communication - operate transparently. Pro-actively communicate your status/progress and respond quickly and clearly to requests for such.
Boost others. Communicate success upward in terms of the team - even if you did it.
Meta-habit: learn to adopt different habits for different situations. With that in mind, some techniques I've found useful for various situations:
"Researchey" green-field development for data-science-like problems:
1. If it can be done manually first, do it manually. You'll gain an intuition for how you might approach it.
2. Collect examples. Start with a spreadsheet of data that highlights the data you have available.
3. Make it work for one case before you make it work for all cases.
4. Build debugging output into your algorithm itself. You should be able to dump the intermediate results of each step and inspect them manually with a text editor or web browser.
5. Don't bother with unit tests - they're useless until you can define what correct behavior is, and when you're doing this sort of programming, by definition you can't.
Maintenance programming for a large, unfamiliar codebase:
1. Take a look at filesizes. The biggest files usually contain the meat of the program, or at least a dispatcher that points to the meat of the program. main.cc is usually tiny and useless for finding your way around.
2. Single-step through the program with a debugger, starting at the main dispatch loop. You'll learn a lot about control flow.
3. Look for data structures, particularly ones that are passed into many functions as parameters. Most programs have a small set of key data structures; find them and orienting yourself to the rest becomes much easier.
4. Write unit tests. They're the best way to confirm that your understanding of the code is actually how the code works.
5. Remove code and see what breaks. (Don't check it in though!)
Performance work:
0. Don't, unless you've built it and it's too slow for users. Have performance targets for how much you need to improve, and stop when you hit them.
1. Before all else (even profiling!), build a set of benchmarks representing typical real-world use. Don't let your performance regress unless you're very certain you're stuck at a local maxima and there's a better global solution just around the corner. (And if that's the case, tag your branch in the VCS so you can back out your changes if you're wrong.)
2. Many performance bottlenecks are at the intersection between systems. Collect timing stats in any RPC framework, and have some way of propagating & visualizing the time spent for a request to make its way through each server, as well as which parts of the request happen in parallel and where the critical path is.
3. Profile.
4. Oftentimes you can get big initial wins by avoiding unnecessary work. Cache your biggest computations, and lazily evaluate things that are usually not needed.
5. Don't ignore constant factors. Sometimes an algorithm with asymptotically worse performance will perform better in practice because it has much better cache locality. You can identify opportunities for this in the functions that are called a lot.
6. When you've got a flat profile, there are often still very significant gains that can be obtained through changing your data structures. Pay attention to memory use; often shrinking memory requirements speeds up the system significantly through less cache pressure. Pay attention to locality, and put commonly-used data together. If your language allows it (shame on you, Java), eliminate pointer-chasing in favor of value containment.
General code hygiene:
1. Don't build speculatively. Make sure there's a customer for every feature you put in.
2. Control your dependencies carefully. That library you pulled in for one utility function may have helped you save an hour implementing the utility function, but it adds many more places where things can break - deployment, versioning, security, logging, unexpected process deaths.
3. When developing for yourself or a small team, let problems accumulate and fix them all at once (or throw out the codebase and start anew). When developing for a large team, never let problems accumulate; the codebase should always be in a state where a new developer could look at it and say "I know what this does and how to change it." This is a consequence of the reader:writer ratio - startup code is written a lot more than it is read and so readability matters little, but mature code is read much more than it is written. (Switching to the latter culture when you need to develop like the former to get users & funding & stay alive is left as an exercise for the reader.)
> Take a look at filesizes. The biggest files usually contain the meat of the program, or at least a dispatcher that points to the meat of the program. main.cc is usually tiny and useless for finding your way around.
This is my #1 pet peeve with GitHub. When I first look at an unfamiliar repo, I want to get a sense of what the code is about and what it looks like. The way I do that with a local project is by looking at the largest files first. But GitHub loves their clean uncluttered interface so much, they won't show me the file sizes!
Check out Octotree if you're using Chrome. No file sizes still, but I've found that when you just want to quickly explore some potential new source this beats having to clone the repo first.
> 2. Collect examples. Start with a spreadsheet of data that highlights the data you have available.
This is true not just for data science but when trying to solve any numerical problem. Using a spreadsheet (or a R / Python notebook) to implement the algorithm and getting some results has helped me in the past to really understand the problem and avoid dead ends.
For example, when building a FX pricing system, I was able to use a spreadsheet to describe how the pricing algorithm would work and explain it to the traders (the end users). We could tweak the calculations and make sure things were clear to all before implementing and deploying the algorithm.
> Don't ignore constant factors. Sometimes an algorithm with asymptotically worse performance will perform better in practice because it has much better cache locality.
Forget the cache, sometimes they're just plain faster (edit in response to comment: I mean faster for your use case). I've e.g. found that convolutions can be much faster with the naive algorithm than with an FFT in a pretty decent set of cases. (Edit: To be specific, these cases necessarily only occur for "sufficiently small" vectors, but it turned out that was a larger size than I expected.) Caching doesn't necessarily explain it I think, it can just simply be extra computation that doesn't end up paying off.
Not faster for sufficiently large N (by definition).
But your general point is correct.
I've best seen this expressed in Rob Pike's 5 Rules of Programming [0], Rule 3:
Rule 3. Fancy algorithms are slow when n is small, and n is usually small. Fancy algorithms have big constants. Until you know that n is frequently going to be big, don't get fancy.
I work with a lot of traders. One antipattern I noticed is that when there's a problem with the data, they'll do all sorts of permutations and aggregations and then scratch their chins and ponder about it for hours.
Go to the fucking source and find an example of the problem! Read it line by line, usually it will be obvious what happened.
Corollary: Don't assume your data is correct, most outliers ina large data set are problems with the data itself. Build a few columns that serve as sanity checks. One good example is a column that shows the distance between this sequence number and the last, anything >1 is a dropped message.
Addition to Performance/2.: Synchronization costs are typically the biggest deal in applications that involve I/O (e.g. hard drive or network). Try an average database transaction with and without synchronization. 1) On sqlite3, it's dozens vs hundreds of milliseconds. Bigger databases, probably not much difference. 2) Lookup NFS sync issues. It's a huge speed/safety tradeoff. 3) On some file systems, a debian installation may take 10 minutes or 90 minutes depending on whether you disabled sync (eatmydata command).
I've been tempted to start a blog...I've gotten a few requests on HN...but I'm still in the "rather be a programmer than a web celebrity" phase. I'm afraid it'll be too much of a distraction from my projects. Plus, I usually write better in response to a prompt than coming up with content in a vacuum.
You could perhaps consider turning a such 'response to a prompt' into a full-blown post on whatever easy-to-use blogging system (Medium, wordpress.com, hell even pastebin or its ilk?), and linking to it alongside a comment.
On HN, I often check specific commenters activity, or new comments in a thread that can be days-old, because I often find hidden gems. A link to more elaboration would definitely count as such. Perhaps an audience of even just a dozen or so people like me might be worth it.
EDIT: Coincidentally (I swear), there's exactly a dozen of comments that positively engage with your comment!
Could you put a link back to the original source in the doc? That way you capture the comments & discussion, which has a bunch of useful clarifications.
Point #5 about unit tests is so true, wish i knew it before jumping on the bandwagon. I wasted so much time writing tdd code only to learn later that the specs had changed. This can save you an insane amount of pain and time.
12 years, plus college, a gap year, and a couple internships & projects in high school.
It's helped that it's really been 12 (well, 13+change) years of experience, rather than one year repeated 12 times. Each year has brought something new and different that's just out of my comfort zone.
Study the idioms of whatever language you are using. If you're writing production code, consistency is everything. Don't write anything surprising or clever - you'll just paint yourself into a corner later, and it'll be impossible to maintain. Boring code is good code.
Take error handling really seriously. A program that can gracefully reject input with a detailed error message is far better than one that crashes mysteriously
Think about your error handling best practices. Mine are:
1. Re-structure your logic so the error cannot happen
2. If you can't do 1, recover from the error silently and continue on with the program
3. If you can't do 2, handle the error gracefully and notify the user of what state is changed, letting them choose whether or not to continue
4. If you can't do 3, inform the user of what happened and ideally provide the user corrective action they can take, then exit cleanly with an error code
5. If you can't do 4, exit cleanly with as descriptive of an error code as you can
6. If you can't do 5, you're probably faced with crashing or exiting with some unhandled exception. This is a bug that should never go into production.
Always be looking for opportunities to move your code up that hierarchy. Moving every 6 to 5 is my personal bar for barely acceptable quality. 4->3 is usually a big win (basically anything that prevents the program from exiting).
"2. If you can't do 1, recover from the error silently and continue on with the program"
I think that defensive programming is the worst way of dealing with errors. You are now silently diverging from your business requirements by making up data.
Thanks for the reply. Yep, this is a topic that reasonable people can disagree about. I suppose I could add "if there's no loss of user data, recover from the error silently and continue on with the program". An example of #2 would be a network connection failure that can be retried without consequence to business logic.
Please, everyone who thinks, "I just expect correct inputs" take note of part two. I've had so many discussions with colleagues about that "Why don't you check for null pointers and give an error message?" "I think it's perfectly fine to just crash with a null pointer, I don't expect null pointers."
That attitude hurts everyone who has to support what you write.
edit: Reformatted as a habit "Make sure whatever you write can be supported without unnecessary headaches."
Only if a.) you can do something to recover from the null pointer or b.) you can provide more information about its cause than you could recover from an ordinary stack trace. Otherwise you're just adding code without changing the ultimate result of the NPE: a debugging session.
Assertions, however, are great. If you can force the program to throw that NPE closer to the point where it actually illegitimately became null, the debugging session becomes much shorter. Null-safety in the type system (like with most modern languages: Swift, Haskell, Kotlin, Scala, Rust, etc.) is even better.
This! I especially see this problem in Java, where IDEs always suggest catching an exception. Like a dog chasing cars, you really should think through what you're going to do when you catch one. I've wasted a lot of time debugging problems that get masked over by try/catch only to pop up at some later point in a seemingly unrelated part of the code.
I have almost never seen a program where you have neither a nor b, but I agree - if you are in a situation where neither a nor b apply, don't do anything.
And: Using a different language is always a great idea, but often not possible.
"Take error handling really seriously. A program that can gracefully reject input with a detailed error message is far better than one that crashes mysteriously"
Wisdom.
One of the most important things, in my opinion, is being able to admit that you don't know or don't understand something. The opposite attitude gets in the way of learning new things, which is really bad for programmers.
This exactly, but let me add: Develop an urge to understand things. One needs to understand the whole system environment just to be able to make good choices.
To give "urge" more meaning: These days I get a noticeable weird feeling in my gut if I'm working in a environment where there are too many unknowns.
> One of the most important things, in my opinion, is being able to admit that you don't know or don't understand something.
further, try to create an environment where others (particularly others who are less powerful) feel comfortable voicing their concerns and are secure enough to state when they don't know or don't understand something.
e.g. if people are worried they are going to be fired or ridiculed in a group setting for not knowing a thing then it would be unreasonable to expect them to say "i don't know".
The most valuable habit I've developed IMO is reinventing the wheel. When you face a new challenge with new concepts you're unfamiliar with, the best way to get a good grasp of the environment/tools/techniques is to rebuild it (them) from scratch. Example: I was spending a lot of time interacting with external REST API's (foursquare, twitter and other services) but never really understood the inner workings, so I just decided to build my own RESTful API for fun. It doesn't really help anybody but now I know what the request / response cycle is and how it works, how to pass headers, what they're used for, the actual meaning of response codes etc.
Oh and also, NEVER make any assumptions about how people will use your software
I think it's important to distinguish reinventing the wheel for practice or understanding, and reinventing the wheel out of stubbornness or "not built here". The first is important because, as you said, it really helps you understand some things that might be rather opaque initially. I didn't understand backpropagation until I implemented it myself.
But what you don't want to do is reinvent the wheel just because you can. Don't write your own crypto, and use whatever FOSS software (with a license approved by your employer) and existing solutions that you can, unless you really need a feature that they don't have. Programming is awesome in part because we can build solutions on top of other pre-exsting solutions; it's 2017 and I can code Python in a web browser with interspersed markdown.
Hard to say any definite habits that work for everyone, as each person is so different, but just for the fun of it, I'll try to list habits that work for me:
* Keep a diary. Write out problems and solution propositions first, if the solution is not trivial.
* Keep your mind clean, always finish what you started, so you can have completion and not clutter your thought process. This means not leaving code in a state of disarray, should compile when returned back to
* Let go. If the solution does not propose itself, take a break. Sleep over it. The solution will come, with time, not by bruteforcing of overdosing caffeine. Sometimes these work too, but as a habit, better to focus on long term goals than short term successes.
* KEEP IT SIMPLE. KISS! When solution starts to look too complex, it probably is. Break it down, simplify, line by line, so that the code is understandable and easy to read. Write for humans to read, not for machines to parse.
* There is no ready made solution. Accept the fact that to get results, work must be done and days and even weeks might go before getting there.
* It's ok to write code that is not "smart", that is not "perfect", that just freaking works right now as should and expected. It's just code, and in the end it all transforms into zeros and ones. Implement new features gradually towards more flexible and standardized solutions, first find a solution for the problem at hand and remember KISS again.
Some of the main points that come to mind. Especially the point of KISS, is so easy to go overboard with, starting to overthink all kinds of fancy structs, class inherintance models, whatever fancy code-beauty around a solution that could be solved with a simple function and evolved later if needed to something more flexible.
This KISS also applies to general software design, user interfaces etc also, probably the most useful habit is to remember when thinking about systems, keep it simple! It should also be fun to write at least in some level, if it feels like crap, don't do it for your own sake.
One way I started to look at KISS is that there are so many ways for software to be complex on higher architectural level, that there is absolutely no reason to make your life harder and go for implementing complex solutions on low level. Get it to a point where it's simple, the complexity will come later.
Assume there's always a better, faster solution to the problem than the one you've come up with. Finding it will require deeply understanding the problem, and sometimes redefining the problem.
Put another way, working long hours is a bad habit because you end up solving problems the brute force way instead of figuring out how to come up with better solutions.
1. Embrace the grind. Motivation comes and goes, but the grind remains. This doesn't mean working all day every day, but rather setting aside specific blocks of time and doing the same thing every single day. Workouts should happen at the same time every day. Work should happen at the same time every day. Each of these things should be daily habits and doing them at the same time every day helps them become habits.
2. Avoid flow[0]. It's tempting, seducing and addicting, but you don't learn anything when you're in a state of flow. Anything sufficiently hard as to improve your skills should leave you feeling a little frustrated. Get used to that feeling.
3. Drop TV, Porn, news, music and video games. These things all give you rewards without having to do any work. In doing so, they steal your motivation and energy.
4. Stop eating sugar. If you want to get things done, strive for a steady blood sugar level. It's hard to work when your blood sugar drops and you fall asleep at your desk.
5. Sleep during the hours of 10pm and 2am[1]. That's when your body makes most of the hormones you need every day.
This is some pretty odd advice. Basically it amounts to "stop doing things that you enjoy". Drop music, news, and video games? Not listening to music will not make you a better programmer. I agree about sugar in moderation and getting good rest (though the specific times seem debatable).
#2 is a serious misunderstanding of flow[0] and is against research arguing that flow states facilitate learning[1].
Flow is not easy-peasy non-frustration time, it is getting "fully immersed in a feeling of energized focus, full involvement, and enjoyment in the process of the activity." To deny yourself that is blocking yourself from the most productive and rewarding of human experiences.
One of the fundamental ideas of flow is that when the task is challenging enough to break one out of the state, additional skills are learned to return to the flow state.[2]
In my opinion, to achieve your maximum potential as a programmer, you should be striving to hit a flow state as much as possible.
I find #3 (minus the music part) to be so important and yet so challenging, having grown up in a house where the TV was ALWAYS on in the background. I spent my teen years falling asleep with the TV on. It feels very uncomfortable at first to forego TV/Movies, FOMO hits hard.
A couple of ideas for taming it.
0) Media detox. It's can be so uncomfortable at first, feel what its like to go without for a week. A similar thing worked for me when I was trying to lose weight, getting used to fasting and what true hunger felt like allowed me to restrict my calories effectively without falling off the wagon.
1) Don't pick up new shows, finish out current seasons and leave it at that.
2) Make a rule that you won't watch TV/movies unless you are watching with someone else, so it's a social activity.
3) Only watch shows when you are working out, cleaning, other mundane task like that. Although you could go the other direction and say those are great activities to practice mindfulness with.
4) Pick one day/week to allow for watching things, ie Part of Sunday is just a lazy day in bed. Kind of like a cheat day.
Active things. Go for a hike, play frisbee, walk the dog, play piano or guitar or whatever floats your boat. The whole point is to work for your rewards instead of getting them instantly at the push of a button.
Recorded music is great. I listen to recorded music all the time when I'm at the gym or at the office. I use it to set the mood. I use it to fill the silence. I use it to block out office noise. But here's the big question: could you go a week without listening to any recorded music at all? You'd be surprised how many people try to stop and find themselves feeling symptoms of withdrawal. That implies some form of psychological addiction, which in turn robs motivation.
The whole point of point 3 is to work for your rewards instead of getting them instantly at the push of a button. It's too easy to get addicted to the latter and with any kind of addiction comes a decrease in motivation.
One habit that I think is important, and often overlooked, is to be able to break out of a mindset and questioning yourself with:
"Am I solving the problem at the correct level, using the appropriate method/technique/tool? Don't forget the big picture"
It's easy to just keep coding and add to existing code, architecture and methods. But sometimes the frog is starting to boil. Better then to re-evaluate whether to do some major refactoring, or add some layer of abstraction to keep it maintainable.
Sometimes you need to recognize that you're merely treating symptoms rather than a underlying problem. Sometimes you need to recognize that there are some library/tool/algorithm etc that can eliminate the need to solve a problem yourself.
Thanks for making that so succinct. I can't count the number of times I've run into code like that.
I used to have scorn for devs that handed code over like that but I've since turned around to thinking that this is mostly due to time crunches. Maybe something worked and then it didn't so they hacked in something and moved on.
Also I have the benefit of seeing this for the first time and not glossing over it with a mental "oh yeah that junk, let me get to the next issue"
So my advice would be like the scouting / camping / hiking saying of leave it better than you found it.
From my 25+ years experience, the main quality for being called great is getting sh*t done. It is never easy because of distorted but still very human mental (tinkering, overthinking, underthinking), physical (laziness, low morale, disorders) and relational (team dynamics, managers, politics) habits.
1. Don't "give up" when trying something new and cut-and-paste and thrash around blindly sticking things places. It takes just as long to learn why things work the way they do as it does to slash and burn -- and you'll pick up something useful along the way
2. Check your ego at the door. A good friend begins a class he teaches having coders say "I'm a programmer and I make mistakes"
3. I've seen a lot of simple systems that did useful things that grew into complex systems. I've never seen a system that started off complex being anything but a huge PITA for everybody involved. Keep It Simple, Stupid
4. Learn all the major programming paradigms and be able to solve problems in all of them. In my opinion, this is the first step to being any kind of programmer at all, much less a great one
5. We write code to help people. We write code alongside other people. People are a critical component, yet we hardly talk about them. Programming is about 95% social, 5% technical. But reading the latest industry news, you'd never think that. Keep your focus on the people, not the tech. Knowing and manipulating the tech is how you get in the game. How your work impacts real people is how you master it. You should be a professional and write clean code, but nobody cares about your standards if you're not getting along with others or making something somebody actually wants
6. Study mistakes and disasters. In every true professional field, folks spend a lot of time picking over and thinking about things when they go wrong. You should do the same. A big part of success is simple failure avoidance
7. Pair/mob program and use TDD if you're deep in OO or complex/mutable code. Nothing shows you how much you still have to learn like making what looks like a simple change and watching dozens of tests go red
8. Keep learning more about text processing and command line utilities. There are a ton of people right now writing complex code for things that can be done in a few lines of shell scripting. Don't try to solve everything in the shell, but know that a little bit of code can replace a ton of work if you know what you're doing.
9. Pick 2 or 3 IDE shortcuts and practice them each week. The less you touch your mouse and the more you can do work without moving your hands the faster you'll be. (This is one I need to work on)
10. Hang out with people that are better than you and pay attention. Greatness tends to rub off over time.
> 3. I've seen a lot of simple systems that did useful things that grew into complex systems. I've never seen a system that started off complex being anything but a huge PITA for everybody involved. Keep It Simple, Stupid
Refactoring is like the Fight Club. Never talk about Refactoring. Instead do it all the time while implementing new features instead of saving it up until the building falls apart.
Understand the tools and languages you use day to day inside and out.
If you know how these things work internally you'll be 3x better than most programmers.
Fail as much as possible in an environment that is okay with failure. My environments have been side projects at home and professional work as well. Make sure you know why it failed and what you can do better next time.
5. Make it failsafe - Handle the edge cases (out of memory, disk full)
6. Make it fast
7. Make it small
8. Make it clean (warnings, lint, beautify/style, clean up dead/commented code, in other words, polish the back of the cabinet)
I've met programmers in school who stop at #1 or #2. Most programming jobs get bogged down endlessly trying to get through the #4 backlog until the deadline comes along and they have to ship. Most developers, when asked to provide an effort estimate for a particular task only budget for #1, #2, and #3 (and with experience will learn to account for #4).
Being "meta", not a in pompous manner, but in a attack all dimensions with simple automation.
See videos like Gary Bernhardt - The Unix Chainsaw on how he gathers very nice data on just about anything in his system with a few pipes. It's easy to try to be awesome in OOP, or in javascript but waste time and energy clicking around or digging manually in repos for information.
I find that is the nicest and most efficient advice I ever took.
The other habit is: improving your maths skills (sophisticated combinatorics, probabilities, statistics) ..
Having just read Masters of Doom, he doesn't give nearly enough credit to diet soda! For me though, I don't feel John Carmack is the kind of guy to hold up like simba to the morning rays. He did his best programming when there wasn't people going on about agile and test driven development and all of the stuff that leeches away at creativity and fun.
Logic and logical thinking - this is the fundamental quality. Thinking, analyzing, contemplating and wondering.
Attention to detail everywhere - be it code or design or documentation.
Communication skills - if one cannot communicate ideas, break them down and simplify them to oneself and others, the work will not really deliver a lot of value over time.
Curiosity to learn more and delve deeper to understand how things work (at a lower level).
Be lazy and optimize - optimize things, avoid repetitive work by building tools and tools that use tools.
"Limited resource" thinking - you may have 16GB RAM, a 4TB drive and a 100Mbps Internet connection, but your users may not. As much as possible, try to minimize things - the size of your program, the amount of data you store, the amount of data you transfer over the network, etc. It might sound silly, but this never goes out of fashion. It just comes back around once every few decades as we invent new devices and ecosystems with different constraints.
Another quote by Kent Beck that I value it highly and practised is "Make it work, make it right, make it fast".
-
I'm not a great programmer myself but some of the habits I've developed and found effective are:
1. to start exercising.
I started running and going to the gym early last year and managed to make it part of my weekly routines now. I feel like I can focus on doing programming tasks much longer now. Oh, and it also helps me in term of accomplishing my short-term goals.
2. to always carry a book
Always be learning. Be it a medium articles, fiction or non-fictions, etc, it doesn't matter. As long as I am constantly learning new stuff, it's fine. It also help keep my ego in check since there are so much unknown I've yet to learn.
3. to stop whenever I'm feeling tired
I take a break from codes every now and then. Sometimes a few days or weeks. This allows me to avoid burnout which I've experienced once in the past.
Pro/Con list everything. Don't read something as a best practice and take it as gospel. If best practices were really best practices, there wouldn't always be new best practices. When you pro/con it, you understand why.
It's not that everyone is full of beans, but what works for their environment doesn't necessarily work for yours. The best shoe size is 10 wide. I know, I've been wearing them for over 20 years.
Also test your assumptions. It's super simple to determine if doing it this way is faster/slower better/worse than doing it that way. Write a short script / console app prototype and put timers on it. It's much faster than arguing endlessly with someone over it. Collect some metrics.
Help the customer on their way to realize what product they want. Don't assume they have it laid out for you. It's a process for both of you, most of the time they do not know exactly what they want at the start.
Spend at least as much time evangelizing what you have developed and promoting it to others as you spent developing it. Otherwise even the best code will risk ending up in a trash can.
This is risky. You can end up investing your time into promoting a turd rather than spending it on writing something better. If your tool isn't obviously useful to the target audience, it needs a UX or documentation improvement at a minimum.
I would state that in a much stronger way --
A programmer should only think of their programming as a tool
and concentrate first and foremost on what they are building.
Good habits should emerge from that bent of mind.
If all you do is code to specs, you will never become a good programmer.
A bad habit of mine is jumping into a problem and trying to get a final & complete solution first time.
This means that I often get bogged down in the finer details and corner-cases before even the most significant functionality is complete because I am trying to deliver a gold-plated, perfect, thought-of-everything solution the first time.
I've found time and time again that it really helps to take a step back, acknowledge to yourself and/or others that there will be TODOs, and start building up the core functionality piece-by-piece starting from the fundamentals and working your way up to the details & corner-cases.
That might mean you play around with a few approaches for an hour, pick one and then commit once, or it might mean that you go through many refactorings and commits over a period of days or weeks.
Whatever approach you take, I've found the feel-good factor/reassurance of having working-code but with known TODOs really helps keep me going and avoids me getting irritated/burnt-out fighting with problems before I've got anything working.
It is not going to be perfect first time, but "mighty oaks from little acorns grow" as they say.
tl;dr - get the fundamentals working first, refactor later to handle the edge-cases or make it sophisticated/elegant.
1. RTFM, I was told this for about every question I had as a beginner, and had to prove that I at least attempted a solution. This was before Q&A sites like we have now.
2. Learn to create head space, be that meditation, yoga, going for a walk, whatever it is for you. Find it and use it to your advantage.
3. Expand your consciousness - Understand you are not the center of the universe, how every you choose to get there.
I've been doing this for 29 years, and I've learnt two useful things. The first is that anything you don't know can be learnt, and if this is your career, probably will be learnt.
The second is that the hardest won skill is getting things done. Whether you hate doing them, have done the thing 1M times before, are bored, or otherwise lack motivation. Applying yourself - really applying yourself only becomes possible when you have a reason to.
They learn their tools really well. I can't tell you how many good professional programmers I know that are utterly handicapped in their speed because they navigate the code base in an inefficient way, can't rename things quickly, can't catch something with the debugger, etc. Once a lot of those inefficiencys are gone it makes more mental room to think about the problem without distractions.
Empathetic coding rather than "show off" coding. Basically rather than trying to impress the next person with the least amount of lines you can write with the most ridiculous variable names, use consistent formatting spacing naming logging and comments to explain your decision process.
Always remember code does not capture the decision process it only captures the outcome.
Two core thoughts that have lead me throughout my professional career is:
How does what I do benefit the customer?
What happens with this if I die tomorrow?
You can code the most elegant, clever and beautiful code in your pet projects but in a professional setting major importance lies in delivering values to the customer and writing code which can be handed over to be maintained by your successor.
There are so many frameworks, tools and layers of abstraction out there that I find it helps to dip down a layer and taste what life is like without framework or tool X. Ideally, it's quite painful and you immediately appreciate what the tool is getting for you. You also might learn that the tool would be very helpful for circumstances you do not currently face (e.g large scale software engineering when you are exploring via a side project), and hang out in the lower layer until further motivated to climb back up.
Some concrete examples:
- you are using THREE.js. Try out raw webgl to draw a square. Run frighted back to THREE.js' arms and have some appreciation for what it is doing for you
- you are new to web development. Try working with the DOM directly. Then try something like knockout or angular that helps track dependencies between your view model and the dom. Then try out React. React has achieved wide-spread acceptance for a reason, I think it's the best pattern. But it's also the most abstract from the reality of what's happening underneath the hood, so taking steps up to the top can really help
- you are playing with scikit-learn and throwing various models at a classification problem. try implementing basic logistic regression using only numpy arrays. Try to understand how you could adapt your implementation `fit`, `transform` and `predict` interface used by sklearn.
A couple of recent articles that show this habit in practice:
2. Be attentive to "flow" and how you achieve it. Space/surroundings, time of date, amount of time, etc.
3. Be aware of your energy level, and match the task to your energy level. Get away from the keyboard and get your brain engaged in other activities to keep you fresh and excited about programming.
4. Write great documentation. This takes as much practice as programming itself. Understand "great" is not equal to "a lot"
5. Don't overbuild on the first pass. Refactoring is your friend.
6. Prototyping is very valuable, but be aware the prototype that doesn't die. I tend to use languages that force the prototype to be thrown away.
7. Profile.
8. Always be learning about your craft and related areas. Business, design, security are all handy when you're a programmer.
9. Don't be a jerk.
10. Learn a variety of languages. You'll likely have a few favorite languages, which is fine, but always be picking up new ideas.
You will never get a group of programmers to agree on such a list. Like the old Jewish saying (paraphrased) for every 3 Rabbis there are 4 opinions. In the end you have to find something that you believe in but be willing to alter if something isn't working, assuming you can tell.
Make it easy to verify what you have written works. This can be done in several ways, and which ones to use depends on the people you're working with and what access to the production code you have. Debug log levels are a popular way to do this.
* Always make a way to examine the data that's coming in (over network, arguments, whatever) to make sure your code is receiving the input it expects, and to be able to predict output/state changes.
* Similarly, have a way to see the data/state changes produced by what you wrote.
* Don't log all this by default.
* ...except for unexpected outcomes. By all means, check your inputs and loudly complain if they are garbage in a way that's unrecoverable.
* Be judicious about how much of this you normally expose to a user; don't overwhelm a user with unactionable noise.
Don't think you are smart. Remember that you are average and that for everyone who you might think you are smarter than there is someone else who is equally smarter than you.
You will move in the direction you face. If you look down on people your skill will diminish. If you look up to people your skill will improve.
Be a dilettante. Do general study of many different fields but recognize the limitations of your knowledge and show the appropriate respect to specialists and experts in their respective fields.
Pay close attention to your errors. Do root cause analysis on every error you make and formulate a plan of action to avoid it in the future.
Analyze your own habits and the habits of your peers. Seek to adopt practices that work for others where possible but only if they prove to work for you as well.
When you see something you don't understand, find out how it works.
There are varying definitions of "understand", but I am confident that I understand something when I can give a lecture on it with no preparation... or when I can code it without checking any references.
Great thread! One of my habits is to try to think of what I learnt the previous day, and if it involves some specific lines of code, briefly go through them to recap. The other is to try to learn something new every day, no matter how little the learning is, I want to feel I did learn something. Consequently, I developed this little app https://everydaycheck.com to track these habits among many others that are not necessarily related to programming.
1. Generous function level and inline comments that explain the rationale behind code organization / approach. Code can be self-documenting, but intentions are not. A great programmer will ensure future maintainers / contributors don't break something for lack of understanding the original context.
2. No magic configurations. No implicit behaviors. Every optional behavior should be explicitly opt-in or opt-out.
3. Treat one as a special case of many. You will thank yourself later when you would otherwise curse the day you were born.
- Ability to avoid buzzwords / marketing mumbo jumbo and identifying true value (or lack of) of any tool
- Remembering you are here to solve a problem, beautiful code is not an end to itself
- Beautiful code is maintainable
- Maintainable code makes you productive
- Productivity is everything: The more problems you, can solve the better you are
- Personally, Hatha Yoga and certain related practices (Kriyas) have rejuvenated me every time I felt burnt out. I'm not a hippy new age shill and if you contact me, I'll share more information.
Every programmer I admire has worked on their chosen field for years. You can keep flitting between languages and frameworks, but mastery ultimately comes from hankering down on one thing and advancing our collective knowledge a bit further. You can achieve mastery in any field - it can be a business domain - as mundane as a Time Tracking or a Todo list app, or it can be a technical domain - like compilers or databases or browsers. You however can't achieve mastery by consuming what others produce. Becoming an expert in CSS and its quirks is a good vocational investment, but you're no closer to a fundamental understanding of the field by just consuming an API.
You should spend years working on a problem domain that interests you. Look at prettydiff (https://github.com/prettydiff/prettydiff). It is a diff tool, a parser, a pretty printer, a minifier, all rolled into one. It is the most comprehensive publicly available tool in terms of language and dialect support in the world right now. Its code is not the most modular and new contributors might have trouble getting in, but its author has been at this problem for years, and if you called a conference for pretty-printing, he would be one among the few thousand people in the world to meaningfully participate.
Consider blueimp's jQuery File Upload plugin (https://github.com/blueimp/jQuery-File-Upload). While this isn't as foundational a work as prettydiff, the project spans seven years and a thousand commits. It solves a mundane problem, but the sheer effort that has went into it makes it a formidable solution.
Consider Martin Odersky, watch Compilers are Databases (https://www.youtube.com/watch?v=WxyyJyB_Ssc). He has been writing compilers for like forever. He's worked on the field for decades, and has written compilers for everything from Fortran to Java to Scala.
You don't have to be a genius to be a master. You just need to go as deep into a field as you can. Here are a few interesting links you might want to read:
(...Don't polarize on one end of the Specialist vs Generalist debate.)
Since improvement of experience and quality of output is roughly logarithmic, it is (depending on the specialisation of the task at hand) better to have a person that has worked ten years to be 7/10 in 5 displines than 10/10 in one and 2/10 in the remaining 4.
Of course, if you only care about the one discipline, get the 10/10 guy. But in real use cases, things are only occasionally atomic, and lack of understanding of adjacent processes and disciplines can prove fatal.
One small addition: if you have the choice between a complex data structure (w/simple algo) or a complex algorithm (w/simple data structure), choose the simple algorithm. It's very often easier to reason about data as it's relatively static, vs a complex algorithm.
Once everything is working then, if it's warranted, change the algorithm.
First you have to define what a great programmer is. Best CS knowledge? Highest Pay? Most prolific? Leading edge?
Knows lots of languages? Most famous? Makes software that users love? Makes profitable companies?
Usually great programmers are good at some of the above but never all, so you have to be clear about what you mean by great. After that its easy :)
Something more habit-like that I am still trying to cultivate: log what you do. It's really useful to be able to look up what you did when. It helps with reviews/invoices, and it helps you get better at estimating how long it takes you to do things, which is essential.
Programming is the art of compromise. All solutions have pros and cons, the first thing to know is what things are more important than others in this situation (performance, maintainability, easy to program, etc, etc) and figuring how to deliver the optimal solution.
attention to quality a.k.a thorough testing, i require that all interviews with dev candidates include being drilled on automation and testing. curiosity to learn new techniques and technologies, is this person playing around with new stacks, languages, etc in his/her spare time, does he/she have open source projects, that tells me that this person is quite passionate about development. i think another one is comprehension of the requirements, often times i see poor developers jump into a solution without fully understanding the requirements.
1. All programmers should drop the "I don't have to be good at math" habit...you're disrespecting people who are likely in possession of knowledge that will help you later. Being "good at math" means you communicate and try to understand concepts. It's more about attitude than knowledge.
2. All programmers should learn Galois theory, not only to get over the idea that they can't be good at math, but to learn to appreciate math. The book by Ian Stewart is good, although I would supplement it with Artin or Dummit and Foote.
3. Try to figure out why Ken Thompson and Dennis Ritchie did what they did, when they did it. Very important for getting a historical understanding of programming. Also, try to figure out why Ken Thompson said what he did in "Coders at Work".
4. Read The New Hacker's Dictionary.
5. Read Naive Set Theory
6. Try (and fail, at least for a year) to read A Shorter Model Theory (don't give up!)
7. Read Code Complete followed by the Python 2.x source code
8. Read SICP and write a scheme interpreter in a language of your choice
Some that occur frequently are:
* Take care of yourself. Get enough sleep, exercise and healthy food. Have hobbies.
* Constantly learn new stuff
* Practice communication skills. Building stuff fast and well doesn't help if you're building the wrong thing, and you need communication skills to prevent that
* Think about the context that your program will run in (related to the reason above)
* Practice empathy