91–100 of 191 posts
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.
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).
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.
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.
Thanks for making me smile.
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 availab…
This article sheds some light on John Carmack's workflow: http://bookofhook.blogspot.in/2013/03/smart-guy-productivity...
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.
They are very concerned about compile times and having a short edit/compile/run cycle.
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.
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 availab…
> 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…
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 availab…
Depth. 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…
(...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.
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:
https://zapier.com/engineering/how-to-build-redux/
https://medium.com/@karpathy/yes-you-should-understand-backp...