How important documentation is. Having to go back to code I wrote years ago, figure out what I was trying to do, relearn specific add-ons/libraries that were only used for that project, then figure out all that has changed/abandoned in the intervening time, avoiding the temptation to start by refactoring... Very difficult, and very easy to be doing unprofitable work because my state of programming mind is so much different each time than the project that is now years older.
Ask HN: For those programming 10+ years, what do you wish you knew 4 years in?
521–530 of 538 posts
Re: Ask HN: For those programming 10+ years, what do you wish you knew 4 years in?
#522I have been developing professionally for 20 years and I'm in my early 40s. What I've learned: * Salary compression is real: most companies are not going to keep giving you raises to match what the market would give you for your skills. They would rather you leave and take all of the institutional knowledge with you than pay you the amount you could get elsewhere. Even if that means hiring someone else at market valu…
> Titles are B.S. but people listen to developers with "architect" as part of their title. I would be careful with this advice. It might get you a cushy job and a higher salary at bad companies, but I think it's bad for your career in the long run. In my experience most "architects" don't do any real work while cooking up a bunch of "best-practices" that sound good in a vacuum but either fail completely or create a b…
I agree. My title has "architect" in it at my insistence, but I'm also the only dedicated developer in the department. So I have to "architect" my own solutions.
Re: Ask HN: For those programming 10+ years, what do you wish you knew 4 years in?
#523Earlier quoted context omitted.
The point of TDD is you can define the behavior before writing the code. ie. you define the expected result: def test_sum(): assert sum(1, 2, 3) == 6 def test_sum_no_args(): assert sum() == 0 def test_sum_negatives(): assert sum(-1, -2) == -3 etc, and then you write the function. This means you only do the "REPL" testing once ever for each case - and you can rerun the tests for all future changes. If ever type the sa…
> if you're in the habit of writing tests after your function is made - it shows you haven't put much thought, which means you haven't done the proper analysis of why the function exists, if the function is really one function or should be two functions, what arguments it can take, what it should return etc. I'd say that's a pretty broad brush you're painting there with
I'm not wrong.
Re: Ask HN: For those programming 10+ years, what do you wish you knew 4 years in?
#524It's all about business/user value. You're not solving useful problems if they're solely technical and don't solve anything useful for someone else. Solve business/user problems with technical solutions, and (1) people will like you more, (2) feeling useful is gratifying, (3) you'll feel more productive with less code, since you'll be focusing on the right output vs code.
Re: Ask HN: For those programming 10+ years, what do you wish you knew 4 years in?
#525Earlier quoted context omitted.
> which compares to a clearly achievable outcome which tens of thousands of people of similar skill levels get offered every year Are you asserting that those five turn over a majority of their mid-career engineers annually? That's the only way I see the tens of thousands number being accurate. As for "mere mortals", I think most of us realize these companies hire them. Hell, I've been interviewing for my company a l…
That's the only way I see the tens of thousands number being accurate. What's your over/under for how many engineers AppAmaGooBookSoft will hire this year? Mine is 50k. I did a back of the envelope calculation for this last year but can't find it. 90% retention rates imply a 5 year survivorship of ~60%; feel free to take any of several thousand HNers out to coffee if you want to confirm what competent, worksmanlike e…
(I work at Google but don't speak for them; I have access to internal retention data but I'm not looking at it or using it here.)
I think 90% retention is (probably?) an underestimate. People tend to look at measurements of tenure, see a short number, and assume Google et al burn people out/have revolving doors. Instead, that's really a function of the still explosive growth we're going through (for better or worse; I say worse but who listens to me?)
(Which still serves Patrick's larger point.)
Re: Ask HN: For those programming 10+ years, what do you wish you knew 4 years in?
#526Earlier quoted context omitted.
TDD seems to be mentioned in a lot of responses here. I'm warming up to the idea but frankly not many folks I've come across in my (short, 3 year) career seem to understand tests really, definitely not TDD. So I've been having to learn the hard way. My main thing with TDD right now is - how do I avoid writing tests that are too tightly coupled? I've gotten burned in the past, not even doing TDD, with tests that "know…
Tests and TDD are different things. I view TDD as a workaround for a lack of a REPL. When the code is finished, the tests can be written or polished but writing them before any code is just one variation of testing.
> I view TDD as a workaround for a lack of a REPL.
Every manual test you do of your code in a REPL is literally a unit test screaming out at you that it wants to live in your suite.
Re: Ask HN: For those programming 10+ years, what do you wish you knew 4 years in?
#527I have been developing professionally for 20 years and I'm in my early 40s. What I've learned: * Salary compression is real: most companies are not going to keep giving you raises to match what the market would give you for your skills. They would rather you leave and take all of the institutional knowledge with you than pay you the amount you could get elsewhere. Even if that means hiring someone else at market valu…
> Titles are B.S. but people listen to developers with "architect" as part of their title. I would be careful with this advice. It might get you a cushy job and a higher salary at bad companies, but I think it's bad for your career in the long run. In my experience most "architects" don't do any real work while cooking up a bunch of "best-practices" that sound good in a vacuum but either fail completely or create a b…
All the architects I met at MSFT were (formerly) star devs, and most still wrote some code (and did code reviews).
Re: Ask HN: For those programming 10+ years, what do you wish you knew 4 years in?
#528~13 years in: Spend your early career, to the maximum extent possible, in well-run organizations surrounded by supportive, skilled teams, so that you can optimize for skill growth and (secondarily at first, but growing over time) for individually attributable impact/ownership. Honorable mention: AppAmaGooBookSoft hire mere mortals, too, and mid-career salary expectations at them are $300k.
Your list on training.kalzumeus.com is not sending confirmation e-mails.
Re: Ask HN: For those programming 10+ years, what do you wish you knew 4 years in?
#529Earlier quoted context omitted.
> Everyone's code basically sucks, including yours. Which is why I'd say, unit-test your code, or TDD, or something. When you look at that crap months later, your mental model of how it all works has completely eroded, and only the test suite is left to preserve your expectations as they existed back then, preventing you from wasting a lot of time stepping on your own toes while you re-grok the big picture, if you ha…
TDD seems to be mentioned in a lot of responses here. I'm warming up to the idea but frankly not many folks I've come across in my (short, 3 year) career seem to understand tests really, definitely not TDD. So I've been having to learn the hard way. My main thing with TDD right now is - how do I avoid writing tests that are too tightly coupled? I've gotten burned in the past, not even doing TDD, with tests that "know…
You know how you manually test code sometimes in a console, like a REPL?
Automate that and you have a unit test.
Do it right before you write the implementation (forcing you to first consider how it might work, not a terrible exercise), and you have TDD.
Every unit of code should be smallish, focused, and with the absolute minimum of external dependencies. That will make it easily unit-testable and far more maintainable long-term.
There's finally empirical data emerging that TDD is a labor-saving device... Look up the Nagappan paper. (There's more than that now, though, that's just the most famous one.)
Also, as someone else mentioned, watch the Boundaries talk by Gary Bernhardt. Amazing.
Re: Ask HN: For those programming 10+ years, what do you wish you knew 4 years in?
#530Earlier quoted context omitted.
I would have upvoted you if it wasn't for your last sentence which is the most hyped in our industry. WRT this sometime ago I wrote this in a S.E. answer: I'm a hater of the sentence "use the right tool for the job". Nowadays, any language can do pretty much anything you want to do with it (except if the language has recently been created and is still in the early stages, e.g.: Elm?). So then IMO these days what you…
Cool :) I use Python for anything related to text processing or webscraping. I use Haxe for when I'm doing cross platform game programming. I use React for web UI / front end work. Erlang for distributed stuff. In each of those cases I've tried other tools and the ones I prefer now seem much more effective ... I've never done anything in F#
You can do text processing and webscraping easily with F#.
React is a framework, not a language (you can still use React with F# if you transpile it to Javascript). You can do cross platform game programming in F# too. And distributed programming of course.