11–20 of 41 posts
There's an 80s book with fantastic interviews of programmers before they became business leaders, check out the reviews: http://www.amazon.com/Programmers-Work-Interviews-Computer-I... & http://www.amazon.com/Programmers-at-Work-Susan-Lammers/dp/0... Some (all?) interviews free here: http://programmersatwork.wordpress.com/
A few tips every developer should learn. 1) Solve the problem before you write the code. 2) Figure out what data structures to use and the code will follow. 3) Debugging is your fault, you screwed up. The language or the compiler didn't (true 99.999% of the time). 4) The difference between genius and insanity is if the algorithm runs faster. The biggest general tip is learn data structures. They are the fundamentals,…
Sometimes the problem is difficult or huge (or both) and you don't know how to solve it. By starting to write some exploratory code, like a solution to a small part of the problem that you do understand, you can frequently get ideas about how to solve the bigger problem. Even if you end up ultimately throwing this code away, it could still be a useful learning experience and help you make progress toward understanding the real solution.
From my experience there are a few things that I try to keep in mind while working. 1) Keep your code as simple as possible. In the real world if you can call your code complex or clever it is probably bad. 2) When presented with a problem don't immediately reach for the keyboard. Take some time to make sure you understand the actual problem that you are solving. 3) Good enough and working beats perfect and not worki…
This principle is often called "kill your darlings".
A few tips every developer should learn. 1) Solve the problem before you write the code. 2) Figure out what data structures to use and the code will follow. 3) Debugging is your fault, you screwed up. The language or the compiler didn't (true 99.999% of the time). 4) The difference between genius and insanity is if the algorithm runs faster. The biggest general tip is learn data structures. They are the fundamentals,…
"1. Solve the problem before you write the code." Sometimes the problem is difficult or huge (or both) and you don't know how to solve it. By starting to write some exploratory code, like a solution to a small part of the problem that you do understand, you can frequently get ideas about how to solve the bigger problem. Even if you end up ultimately throwing this code away, it could still be a useful learning experie…
Seriously, listen to the talk and/or check out the slides.
But 90% won't, so here's her actionable steps:
1. Ask why obsessively
2. Teach and/or speak at an event
3. Work through a suggested curriculum*
4. Experiment recklessly (the code doesn't care)
5. Have opinions
6. Seek mentorship
7. Program a lot
8. Stop fucking programming sometimes.
9. Write Javascript* a lot
10. Write in another language for a while
11. Think like a programmer when afk
12. Know what feedback is good feedback and reject everything else.
13. Break free of imposter syndrome
There's a great presentation on the topic by Angelina Fabbro www.youtube.com/watch?v=v0TFmdO4ZP0 with matching slides http://afabbro.github.io/jsconf2013 . The title says javascript, but it's really a platform agnostic guide that sketches out what mastery looks like and lays out actionable steps to get there. Seriously, listen to the talk and/or check out the slides. But 90% won't, so here's her actionable steps: 1.…
There's an 80s book with fantastic interviews of programmers before they became business leaders, check out the reviews: http://www.amazon.com/Programmers-Work-Interviews-Computer-I... & http://www.amazon.com/Programmers-at-Work-Susan-Lammers/dp/0... Some (all?) interviews free here: http://programmersatwork.wordpress.com/
There's also a more recent book of interviews with well-known programmers called Coders at Work : http://codersatwork.com