41–50 of 191 posts
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.
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 pr…
> * Practice empathy 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).
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.
+
There is no one true way.
=
Anybody that claims that there is only one way to do something is selling dogma.
that and, listen to many voices, especially those that aren't the loudest.
"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.)
A few habits I've found that work well for me: 1. Start small, then extend. 2. Change one thing at a time. 3. Add logging and error handling early. 4. All new lines must be executed at least once. 5. Test the parts before the whole. 6. Fix the known errors, then see what’s left. Taken from here: https://henrikwarne.com/2015/04/16/lessons-learned-in-softwa...
A few additions 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…
A few habits I've found that work well for me: 1. Start small, then extend. 2. Change one thing at a time. 3. Add logging and error handling early. 4. All new lines must be executed at least once. 5. Test the parts before the whole. 6. Fix the known errors, then see what’s left. Taken from here: https://henrikwarne.com/2015/04/16/lessons-learned-in-softwa...
What if you write a function in Go that's littered with the usual
if err != nil {
return err
}
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.
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 pr…
> * Practice empathy 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).
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.
Oh and also, NEVER make any assumptions about how people will use your software