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

I think you may have misunderstood me a little.

I'm not saying go use the Servlet API directly all the time but you damn well should know it since almost all the others build on top of it (including most of Jersey).

Particularly Servlet Filters. It seems like every framework has their own take on onion processing a request but servlet filters are actually easier to write then say some Spring framework "Advise".

As for Dropwizard... You do know its built on top of all the new JEE stuff like JAX-RS. I am willing to wager it will die and be replaced with something else... but those underlying javax specification stuff (like JAX-RS, servlet api, etc) are still going to be around.

You should know those underlying standard APIs.

The funny thing about you mentioning Dropwizard is it basically started as someones else stack built by mixing standard libraries.... something companies do all the time.

> I see no benefit, in 2017, to using servlets directly. It's certainly not going to be easier to teach a new hire through look-at-the-code or look-at-our-minimal-doc instead of pointing them at the existing documentation and examples of best-in-breed tooling.

Until shit breaks, or doesn't fit your exact requirements or the project dies, etc, etc, etc and believe me it does happen in which case you will need to know the lower level stuff. But yeah don't reinvent the wheel.

> The boundary between a beginner and a coding rockstar really isn't very great

I respectfully disagree. My experience says the difference between a beginner and a really good, experience coder, is HUGE, and not only on fields like "machine learning" but in everyday commercial systems.

Unless, of course, your platform is something like Java where everybody is crippled to an extreme degree.

That is, if you get 400 people on a room, tie their hands and their feet, they most likely dance with the same skill, their dancing experience notwithstanding ...

My number one piece of programming advice is that you can always find a simpler way - and if you have R&D time to sink into simplifying your problem, doing so is a good idea - but actually simplifying is a very hard task and there is no blogpost tip or design pattern that will do it: it requires knowing your problem very deeply and being willing to shave a few yaks and reinvent a few wheels and generally grind away at something that was already solved, but in a way you find dissatisfying.

If the problem is genuinely original to you, your best bet is to find the biggest leveraging factors(language, tools, libraries, etc.) and consistently lean on those to arrive at a solution fast, then pay down the resulting debt in dependencies, performance and gaps in UX later. This can actually aid in an R&D effort because reaching a clunky solution quickly will lend a certain maturity to the codebase and the problem you're addressing. But it means being willing to read and reuse code that you are personally uncomfortable with and know does not really solve the specified problem exactly. This is a revision-heavy process and it's antithetical to what many programmers are inclined to do - which is to get everything finalized in one shot, drawing on all the stuff they know is the "best practice" even if it's tangential to shipping.

The more you're willing to allow your code to be "knowingly wrong" in ways that are easy to call out and to return to later, the faster you can get to the stage when actually revising it has value. This is why everyone writes bad code yet some code looks better than others: the good code was bad code that solved the right problem, then revised.

I'm self taught and will never get a degree, unless it's for fun and completely unrelated to CS. The recruiters at those companies skipping me over are just doing a part of my job for me - filtering out places with culture that I wouldn't want to work at.

Here are a couple things that have served me well:

* Own what you own 100%. Be proactive, ask questions so you understand context, and raise concerns along with possible solutions when they pop up.

* Help others when you can. If you are going to be in this industry a long time, your network of colleagues and friends will help you long past your current gig. They can help you solve problems and avoid bad technical choices and when you are ready to move on, they can help you find a new job. The kindness you show others pays off in many ways.

* It's easy to get emotional when you are passionate about a job or a project and that passion can quickly turn into anger. Before sending an inflammatory email, sleep on it.

* Learn the tools of your trade well. Know your editor, debugger, devstack, monitoring tools, deployment tools, etc. I'm a bit hyperbolic but the single best thing I did in the last 20yrs was learn vim well.

* Work hard but pace yourself. Put aside time for yourself to stay healthy.

* Enjoy the moment even when it's stressful. You'll eventually look back on your career and see that the highlight reel features some "against all odds" moments and battle scars.

* Keep learning