Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Ask HN: For those programming 10+ years, what do you wish you knew 4 years in?

news.ycombinator.com

Post reply on HN
Print view View original

461–470 of 538 posts

Re: Ask HN: For those programming 10+ years, what do you wish you knew 4 years in?

#461

Post by AnimalMuppet »

bitL wrote: post #331
AnimalMuppet wrote: post #322

Earlier quoted context omitted.

False so far, and I'm 55. I kick the rear end of fresh graduates. They can type a lot faster, turn out more lines of code per day. Great. I don't write the bugs that they write, so I don't have to take the time to find and fix them. I don't make the design mistakes that they make, so I don't have to fight the design flaws to get things done. They work harder; I get more done, and I get paid accordingly. And if you th…

You are probably in 1% of lucky ones. Imagine you have a bad year (sickness, family issues etc.) and you don't have management that is used to you around (e.g. there is a reshuffling). How long would you manage to stay? You should put this into your equation. I also dislike being a manager but I am more capable manager than all managers I've been under (maybe I am just unlucky but I don't think so). We all know the b…

> I also dislike being a manager but I am more capable manager than all managers I've been under (maybe I am just unlucky but I don't think so).

In my case, I'm pretty sure that I wouldn't be better than the ones I've been under (maybe I would be better than one or two, but not the majority). I'm also more likely to get fired as a manager, due to a tendency to say what I think.

If you're a better manager than the managers you've been under, you may be of more value to your company as a manager (even if you hate it). I may be selling myself short, but my value as a manager could be less than zero...

Re: Ask HN: For those programming 10+ years, what do you wish you knew 4 years in?

#462

Post by hex13 »

sk1pper wrote: post #418
pmarreck wrote: post #315

Earlier 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 could divide (in your head) contract and implementation details. Contract - what "unit" should do, e.g. factorial function should compute factorial for given numbers. But how exactly this is done is implementation detail (will be used recursion? do/while loop? will there be result caching?)

The trick is to omit implementation details from testing, because implementation can change, but after all fact(4) should return 24 no matter what.

So it's useful to think in categories of contract given unit should fulfill instead of testing everything for the sake of testing.

Re: Ask HN: For those programming 10+ years, what do you wish you knew 4 years in?

#463

Post by lsiebert »

cookiecaper wrote: post #359
tekstar wrote: post #289

Earlier quoted context omitted.

> The boundary between a beginner and a coding rockstar really isn't very great unless you are getting into the realm of computer sciences, like machine learning. This is really untrue. On the surface, code might look the same between a beginner and a senior developer, but the decisions underlying the code will be night and day. Beginners will solve the problem of the day directly, with no care for introducing comple…

My interpretation is that most of this disagreement is just from ambiguity left by the parent's brevity. Experience certainly shines bright in architectural and design decisions. I think the parent's point is that no one's code should be considered sacrosanct; all of us can make mistakes, and all of us, even the senior guys, will end up writing some ugly hacks just to get something out the door on time. More junior p…

That's why comments should mostly indicate the why of a design/architecture choice that was made, not what the code is doing.

Re: Ask HN: For those programming 10+ years, what do you wish you knew 4 years in?

#464

Post by zachrose »

sk1pper wrote: post #418
pmarreck wrote: post #315

Earlier 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…

Three answers:

1) Just keep going. Experiencing the pain of less-than-ideal tests is pretty much the best way to learn. It also frees you from outdated dogma about testing.

2) Maybe try testing at different levels? I got into testing by learning to write big slow acceptance tests for a particular user experience and small fast unit tests for a particular module. This helped me see what each kind of test was best for. (Maybe your "big tests" are written in Cucumber and automate a web browser, maybe they test an HTTP API, that's up to the kind of work and environment you're in.)

3) Watch this video "Boundaries" by Gary Bernhardt: https://www.destroyallsoftware.com/talks/boundaries

Re: Ask HN: For those programming 10+ years, what do you wish you knew 4 years in?

#467

Post by ge96 »

tekstar wrote: post #422
ge96 wrote: post #413

Earlier quoted context omitted.

Probably unrelated It pisses me off how I keep having to rewrite/resolve this particular problem I have of deploying a photo sharing site based in a poor network area. One day I feel satisfied with the work I've just done, the next day it is garbage and I do it again a different way. Faster but not fast enough. Then you get this huge block of code and feel this heavy weight like ahhh.... Slash and burn... Am I doing…

Ahh, rewrite vs letting it stay! The classic maintainer dilemma! Answering this really depends. I think I would start with "what do I hope to get out of this process". Are you doing this to learn? Are you doing it to grow a user-base? If it's a user-base, is this the biggest problem preventing your growth? If it's learning, is this the most interesting problem for you to solve?

I'm doing it because the site is too slow where people don't stay/staring at a loading icon. 0.5Mbps and lower is really annoying to deploy a photo-based site gee who would have known.

The Dom loads just over 1 second, but things are still waiting to show up(js?) So I'm thinking of building empty templates like "Hey something is here don't worry."

I don't know. I'm actually not sure what progressive loading is. I currently use that blur-up method but I've seen those sites that use a technique where the photo is super pixelated (large pixels about a quarter of an inch or 1/8) before loading the high res. I think that is true progressive loading but don't know what it means with code.

Re: Ask HN: For those programming 10+ years, what do you wish you knew 4 years in?

#468

Post by flukus »

sk1pper wrote: post #418
pmarreck wrote: post #315

Earlier 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…

> 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.

You aren't wrong, the state of unit tests in the wild is dreadful. Many were forced into creating tests by management decry, others just think they know what unit testing is. Sometimes the latter are even unit testing advocates.

Remember what a unit is, it's not a class or the method, it's the unit of behavior you are testing. In practice this basically means whatever you are asserting.

Stick to the single assert principle and keep tests small. This doesn't mean only one assert statement, but only one behavior. Often asserting that a function returns an object will one test (it didn't return null), the details of the fields that object contains (like did we format "LastName, FirstName" properly) will be different tests. If you are asserting "LastName, FirstName" in 10 tests then 10 tests will break when that behavior changes. Only one test should break.

Always have a setup method that creates the owner of the unit and any of it's (mocked) dependencies. When a behavior is added it should take less than a minute to add the test for that behavior (assuming the test fixture already exists).

Do that and you're writing better tests than 95%+ of the industry.

Re: Ask HN: For those programming 10+ years, what do you wish you knew 4 years in?

#469

Post by njwi332 »

annnnd wrote: post #52
patio11 wrote: post #48

~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.

> AppAmaGooBookSoft Interesting... I have always steered clear of such jobs because I felt I would be just a cog in the machine. It seems to me only a select few in those organizations ever shine (and most of them achieved their status before joining AppAmaGooBookSoft). Am I mistaken?

As someone who has worked for the 'Ama' part of that portmanteau for the last 2 years, and before that 5 smaller companies.

I would say it is a strange but not bad combination of being a cog + having autonomy. I feel like a cog in a very big machine, there are many other teams i interact with, but simultaneously I have more autonomy within my own business line than any other company I've worked in. I'm constantly asked to think of new ideas and ways we can improve our processes, architecture etc and have gotten to prioritise my own work on things that I thought were important.

I'm not sure if I'd say I'm 'shining', but I'm earning more money than I dreamed possible while learning from a lot of smart people, which lines up with pat's experience.

Re: Ask HN: For those programming 10+ years, what do you wish you knew 4 years in?

#470

Post by honopu »

ge96 wrote: post #467
tekstar wrote: post #422

Earlier quoted context omitted.

Ahh, rewrite vs letting it stay! The classic maintainer dilemma! Answering this really depends. I think I would start with "what do I hope to get out of this process". Are you doing this to learn? Are you doing it to grow a user-base? If it's a user-base, is this the biggest problem preventing your growth? If it's learning, is this the most interesting problem for you to solve?

I'm doing it because the site is too slow where people don't stay/staring at a loading icon. 0.5Mbps and lower is really annoying to deploy a photo-based site gee who would have known. The Dom loads just over 1 second, but things are still waiting to show up(js?) So I'm thinking of building empty templates like "Hey something is here don't worry." I don't know. I'm actually not sure what progressive loading is. I cur…

server side render or put in HTML as placeholder. I've wanted to placeholder images with the primary color or some gradient that can be made in canvas but never got around to it for a project.
Post reply on HN