Hacker News new | past | comments | ask | show | jobs | submit login
Ask HN: What is your best advice for a junior software developer?
470 points by nothing_to_see on Oct 3, 2018 | hide | past | favorite | 453 comments

Read the error messages. Reread them. Extract every piece of information from them. Never close an error popup without having read and understood what it means. Always read stack traces when you're blessed enough to have them.

100% of the juniors (and an awful lot of seniors) I've ever trained simply ignore those and then come ask for help debugging.

99% of the time, the explanation for their problem is literally the first line of the stack trace/error message/whatever is red on their screen.

If you successfully adopt the mindset of "whatever the computer is telling is true from the computer point of view, so I'd better make sure I've read it" instead of "Anyway, I'll try something else and run again", you'll debug 10 times faster. And since debugging is a good part of the job, you'll be a lot more productive.

I really like your last point "whatever the computer is telling is true from the computer point of view".

In a surprising number of coding interviews that I've conducted, I've seen a candidate write an incorrect solution that generates an exception and then attempt to figure out the error almost on first principles, rather than actually reading the exception carefully and thinking about what coding errors could have caused it to happen. The exception message is a _huge_ hint!

It's a red flag to see someone try to debug without paying attention to it. Conversely it's very positive to see someone encounter one and then think carefully about it. Writing an incorrect solution but then testing it out and showing the ability to debug and fix it systematically and expediently is no worse than getting it right on the first try, in my book.

It isn't just a huge hint, most of the time it tells you exactly what the damn issue is. This discussion is blowing my mind.

I am honestly speechless. IT GIVES YOU THE LINE NUMBER AND THE FUNCTION CALL AND THE REASON! Why would you ever even attempt to debug without parsing it?

Wait wait wait.

Not so fast.

i'm one of those programmers who read manuals and stack traces but I have to admit that I've seen my share of both manuals as well as stack traces that didn't make much sense.

This is my experience with Clojure stack traces ~60-75% of the time. Perhaps it is a symptom of functional programming? A lot of function passing and anonymous functions make it difficult to generate a meaningful stack trace.

Clojure's stack traces are an issue with Clojure specifically, and how it's hosted on top of the JVM. A lot of the stack trace you get is actually implementation details of the Java objects making up the Clojure runtime. In effect, the program that you get stack traces of is the Clojure interpreter rather than your Clojure program which is running inside that interpreter.

Why do they do this, though? Shouldn't they have realized from the start that such messages are not helpful, and should have given messages related to your Clojure program? (Or is there some difficult technical issue related to achieving this?)

Asking because reading about this issue in the past is one thing that has kept me from trying out Clojure.

I've heard similar things about Scala, though I haven't had a chance to confirm this for myself yet. Not 100% sure if this supports your hypothesis or not given that Scala is multiparadigm?

Fortunately, I think 1.10 is going a long way towards fixing this.

My experience in Racket has been the opposite. Especially with the aid of DrRacket's stepping debugger, reading stack traces and finding bugs is rather painless. (Figuring out the best way to fix bugs, however, is no easier than in any other language.)

Functional programming not so much- languages like Elixir or JS used functionally don't have this problem generally.

Elixir has had difficult to parse error messages until relatively recently, but this has improved immensely (Dialyzer/Dialyxir in particular).

In what way? I've been using Elixir since late 2015 and have rarely had issues.

Yeah I agree. The way this thread is going you would think that all errors are easy and all you have to do is what the computer tells you and you’re done. I wish I’d known it was all that simple!

> stack traces that didn't make much sense.

Those can be especially prevalent in systems that utilize a lot of indirection.

Especially when you end up in C++ template hell.

That kind of stuff permanently damaged my ability to enjoy using C++.

Error in boost/bind.hpp:768

That's exactly what I felt as I was spending time on MSDN/Microsoft support website, reading about weird errors messages on Windows 95/98/NT/XP in 1990s. Some generic desc about the Windows error messages and no resolution.

as in tensorflow stack traces

And in the opposite direction: remember when you are writing error messages to include all the relevant details, and never ever write "this shouldn't happen" or "document later".

What about, log_panic("If we have somehow managed to hit this code path, this project if FUBAR. I would recommend giving up and starting over.")

Somehow reminds me of Aliens:

  I say we take off and nuke the entire site from orbit. It's the only way to be sure.

That's annoying but fine as long as it's unique and you can grep it in the codebase.

You can forgo something being unique if you just append line and file information to the log. Literally any logging framework (even homerolled ones) should give you this by default.


If used correctly, «this should not happen» can be very useful, indicating e.g that the program is in some illegal state, as opposed to the input being incorrectly formatted.

Even if that’s the case, create a custom exception and embed in the custom exception object the actual exception.


That’s only true if the developer of the class module let the entire stack trace get through to the consumer.

In C# it’s the difference between...




}catch(Exception e)


//Do stuff

   throw new MyCustomException(“Something Bad happened”);





}catch(Exception e)


  //do stuff



Erh, exception types should include an inner exception parameter, for the generic one they wrap. So neither of your two examples are all that great.

Why would I wrap an exception if I don’t plan to have special handling? If it is exception that I didn’t throw because of a business reason, why not just throw the original exception?

If you don't have any special handling, then why are you catching it at all?

That was the "//Do stuff" part, you may want to do some cleanup (in C# usually handled by a finally block or a "using" block), send a custom notification, logging (usually I would just let the client handle logging), etc.

In what case would you ever want the second example?

Always. If you can't resolve the exception and continue processing normally, you should never discard the exception you caught and create a new one of your own. If you must create one of your own, include the one you caught for the additional context.

It's pretty frustrating when you're debugging someone else's code and their error handling just throws away all of the useful information and replaces it with a generic "Something broke" kind of message.

usually you may catch a general exception and throw another one that's caught up the call stack. In this case i think it may be useful for logging additional causes that are not going to be obvious with just the stacktrace(?)

I remember once encountering an error that had all of the above plus it presented the solution to the issue right in the error message. It was amazing and why I still remember seeing that to this day.

Let's try that! I was trying to do some trivial task on a .gov website, but was greeted with the following, which I'm pasting here for your convenience. Could you spot the problem? Because their customer service can't.

Error Page Exception SRVE0260E: The server cannot use the error page specified for your application to handle the Original Exception printed below.

Original Exception: Error Message: javax.servlet.ServletException: /verification.xhtml at line 66 and column 34 action="#{verificationAction.authenticateClient()}": java.lang.NullPointerException Error Code: 500 Target Servlet: Faces Servlet Error Stack: javax.el.ELException: /verification.xhtml at line 66 and column 34 action="#{verificationAction.authenticateClient()}": java.lang.NullPointerException at org.apache.myfaces.view.facelets.el.TagMethodExpression.invoke(TagMethodExpression.java:95) at javax.faces.component._MethodExpressionToMethodBinding.invoke(_MethodExpressionToMethodBinding.java:88) at org.apache.myfaces.application.ActionListenerImpl.__AW_processAction(ActionListenerImpl.java:100) at org.apache.myfaces.application.ActionListenerImpl.processAction(ActionListenerImpl.java) at javax.faces.component.UICommand.broadcast(UICommand.java:120) at javax.faces.component.UIViewRoot._broadcastAll(UIViewRoot.java:995) at javax.faces.component.UIViewRoot.broadcastEvents(UIViewRoot.java:278) at javax.faces.component.UIViewRoot._process(UIViewRoot.java:1307) at javax.faces.component.UIViewRoot.processApplication(UIViewRoot.java:733) at org.apache.myfaces.lifecycle.InvokeApplicationExecutor.execute(InvokeApplicationExecutor.java:34) at org.apache.myfaces.lifecycle.LifecycleImpl.__AW_executePhase(LifecycleImpl.java:172) at org.apache.myfaces.lifecycle.LifecycleImpl.executePhase(LifecycleImpl.java) at org.apache.myfaces.lifecycle.LifecycleImpl.__AW_execute(LifecycleImpl.java:119) at org.apache.myfaces.lifecycle.LifecycleImpl.execute(LifecycleImpl.java) at javax.faces.webapp.FacesServlet.__AW_service(FacesServlet.java:189) at javax.faces.webapp.FacesServlet.service(FacesServlet.java) at com.ibm.ws.webcontainer.servlet.ServletWrapper.service(ServletWrapper.java:1233) at com.ibm.ws.webcontainer.servlet.ServletWrapper.handleRequest(ServletWrapper.java:782) at com.ibm.ws.webcontainer.servlet.ServletWrapper.handleRequest(ServletWrapper.java:481) at com.ibm.ws.webcontainer.servlet.ServletWrapperImpl.handleRequest(ServletWrapperImpl.java:178) at com.ibm.ws.webcontainer.filter.WebAppFilterChain.invokeTarget(WebAppFilterChain.java:136) at com.ibm.ws.webcontainer.filter.WebAppFilterChain.doFilter(WebAppFilterChain.java:97) at com.icbc.licensing.filter.ThreadContextFilter.__AW_doFilter(ThreadContextFilter.java:92) at com.icbc.licensing.filter.ThreadContextFilter.doFilter(ThreadContextFilter.java) at com.ibm.ws.webcontainer.filter.FilterInstanceWrapper.doFilter(FilterInstanceWrapper.java:195) at com.ibm.ws.webcontainer.filter.WebAppFilterChain.doFilter(WebAppFilterChain.java:91) at org.apache.logging.log4j.web.Log4jServletFilter.__AW_doFilter(Log4jServletFilter.java:71) at org.apache.logging.log4j.web.Log4jServletFilter.doFilter(Log4jServletFilter.java) at com.ibm.ws.webcontainer.filter.FilterInstanceWrapper.doFilter(FilterInstanceWrapper.java:195) at com.ibm.ws.webcontainer.filter.WebAppFilterChain.doFilter(WebAppFilterChain.java:91) at com.ibm.ws.webcontainer.filter.WebAppFilterManager.doFilter(WebAppFilterManager.java:967) at com.ibm.ws.webcontainer.filter.WebAppFilterManager.invokeFilters(WebAppFilterManager.java:1107) at com.ibm.ws.webcontainer.servlet.CacheServletWrapper.handleRequest(CacheServletWrapper.java:87) at com.ibm.ws.webcontainer.WebContainer.handleRequest(WebContainer.java:949) at com.ibm.ws.webcontainer.WSWebContainer.handleRequest(WSWebContainer.java:1817) at com.ibm.ws.webcontainer.channel.WCChannelLink.ready(WCChannelLink.java:200) at com.ibm.ws.http.channel.inbound.impl.HttpInboundLink.handleDiscrimination(HttpInboundLink.java:463) at com.ibm.ws.http.channel.inbound.impl.HttpInboundLink.handleNewRequest(HttpInboundLink.java:530) at com.ibm.ws.http.channel.inbound.impl.HttpInboundLink.processRequest(HttpInboundLink.java:316) at com.ibm.ws.http.channel.inbound.impl.HttpInboundLink.ready(HttpInboundLink.java:287) at com.ibm.ws.tcp.channel.impl.NewConnectionInitialReadCallback.sendToDiscriminators(NewConnectionInitialReadCallback.java:214) at com.ibm.ws.tcp.channel.impl.NewConnectionInitialReadCallback.complete(NewConnectionInitialReadCallback.java:113) at com.ibm.ws.tcp.channel.impl.AioReadCompletionListener.futureCompleted(AioReadCompletionListener.java:175) at com.ibm.io.async.AbstractAsyncFuture.invokeCallback(AbstractAsyncFuture.java:217) at com.ibm.io.async.AsyncChannelFuture$1.__AW_run(AsyncChannelFuture.java:205) at com.ibm.io.async.AsyncChannelFuture$1.run(AsyncChannelFuture.java) at com.ibm.ws.util.ThreadPool$Worker.run(ThreadPool.java:1892) Caused by: java.lang.NullPointerException at com.icbc.licensing.clio.action.VerificationAction.DbAuthInsertandCount(VerificationAction.java:118) at com.icbc.licensing.clio.action.VerificationAction.__AW_authenticateClient(VerificationAction.java:161) at com.icbc.licensing.clio.action.VerificationAction.authenticateClient(VerificationAction.java) at sun.reflect.GeneratedMethodAccessor440.invoke(Unknown Source) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:56) at java.lang.reflect.Method.invoke(Method.java:620) at org.apache.el.parser.AstValue.__AW_invoke(AstValue.java:268) at org.apache.el.parser.AstValue.invoke(AstValue.java) at org.apache.el.MethodExpressionImpl.invoke(MethodExpressionImpl.java:278) at org.apache.myfaces.view.facelets.el.TagMethodExpression.invoke(TagMethodExpression.java:83) ... 46 more

Error Page Exception: Error Message: javax.servlet.ServletException: WebBeans context with scope type annotation @RequestScoped does not exist within current thread Error Code: 0 Target Servlet: Error Stack: javax.enterprise.context.ContextNotActiveException: WebBeans context with scope type annotation @RequestScoped does not exist within current thread at org.apache.webbeans.container.BeanManagerImpl.__AW_getContext(BeanManagerImpl.java:363) at org.apache.webbeans.container.BeanManagerImpl.getContext(BeanManagerImpl.java) at org.apache.webbeans.intercept.NormalScopedBeanInterceptorHandler.getContextualInstance(NormalScopedBeanInterceptorHandler.java:125) at org.apache.webbeans.intercept.NormalScopedBeanInterceptorHandler.invoke(NormalScopedBeanInterceptorHandler.java:96) at org.apache.webbeans.conversation.ConversationImpl_$$_javassist_0.isTransient(ConversationImpl_$$_javassist_0.java) at ...

verifcationAction.authenticateClient() call hit a null ref exception (called from the template at /verification.xhtml) and their error page is trying to use a webBean context which hasn't been setup or activated yet to display the error.

The original site of the null ref error seems to be the DBAuthInsert method at com.icbc.licensing.clio.action.VerificationAction.DbAuthInsertandCount(VerificationAction.java:118) so maybe a getConnection is returning a null and not being checked, or some config variable is borked. Would start digging at line 118 to work out what variables are being dereferenced and where their values come from.

The server process running in a thread other than the router? Dunno, I’m sure I could figure it out having access to the code. Support most likely does not employ software engineers / SREs.

In my experience, the progression of skill comes almost full circle. Juniors don't read error messages and try to debug "from first principles". Seniors pay attention to error messages. Experts often don't (initially) read the error message, because the very fact that there is an error immediately clues them in on its likely cause.

I had a candidate once. They were having trouble getting the message body on a 400 level error during the technical interview. They had chosen to solve it in Java. I'm not a Java developer (and I let the candidate know ahead of time and that I could only help with naive suggestions). Their exception message was pretty clear. After they prodded around for a bit getting nowhere, I pointed out the exception message. He ignored my suggestions multiple times (multiple angles of "your exception says blah"). After the interview, I took his solution and fixed it per the exception message. Boom. Worked. After the interview, his feedback to our recruiter was that it was obvious I did not know Java. Some people are bad at reading and listening :(. Also, this was a former Googler. It helped shatter an (unconscious?) bias that somehow Googlers were a breed above the rest.

In principle, I couldn't agree more. I get this from time to time, someone is stumped on an exception and after seeing it, I usually go "well, it's a null pointer exception in this method, so from looking at the code, it could come from these 3 places".

The pattern I see there is that a) in release builds, exceptions on many platforms suck. Things get inlined, parts of the stack trace are missing etc. If you understand why that is, that's not so much of a problem. But: b) people often have this Voodoo-like mentality about this. They often see the 100th stack trace that doesn't make much sense and try to wing it, because that's obviously always the case. The best thing you can do look at them together: Lead by example, think aloud and you might just teach someone how to read it in a better way.

It's rather important you have a consistent and accurate mental model of why your stack traces are mangled, lest you end up like one of those beasts that got random treats in B.F. Skinner's experiments and ended up with the strangest behaviors possible :-)

People never read error messages. Most of them click straight through 8 milliseconds after the error appears, without taking the slightest opportunity to understand.

It's rage-inducing when troubleshooting over laggy screensharing sessions. If enough frames drop, I may not even see that the error was raised.

Related: Read the official documentation. I can’t count how many times junior folks have asked me things like, does FooBarFactory constructor take an array of ints or floats? Well, what does their documentation say? Sometimes the official documentation is crap and that’s a reasonable question, but usually the answers can be found in TFM.

I noticed a similar trend in JS dev: asking/looking for (video) tutorials instead of reading the official doc. Even when the doc is good and quick too read (React, Redux, Vue, etc).

Related to that, usually I am a little faster finding answers to syntax questions on SO than in the documentation, even when the documentation is good. So I'm glad that people have been asking those basic questions on SO.

Yeah, it's a bit weird why people have this expectation to reach for tutorials by random person X instead of looking for the official docs. I can't count the number of time someone asked me which tutorials to read to learn Go, but hadn't even considered reading the docs.

I tend to grok things a great

I work in QA and I wish more developers thought this way. Also run your code before hand off. Please. If I had a nickel for every time I got a user story or bug to validate and it immediately crashes then I would have a bunch of nickels. Which wouldn't be super helpful, but still. Please at least run your code, or ideally you should have CI/CD with unit tests, but we all know that isn't always the case especially in legacy Enterprise software.

It's easy to make the assumption that developers haven't ran the code at all, but I find in reality that's rarely the case. In my experience it almost always has something to do with an unexpected environment variant.

It's very easy as a developer to get so comfortable with the "happy path" of navigating code that you forget to look outside of the happy path when devising your test cases. It takes time to learn to identify the test cases you're not regularly exposing yourself, and these test cases are often ones not described in a requirements or specs doc.

This! I spent the first half of my career in QA. This second half in dev. Coming from QA I'm very meticulous about everything and yet as soon as it leaves my hands something comes up. This is why I'm a big proponent of QA. I had a chat with someone who was pretty much dismissing QA because they had the mindset of I'll just test it or my cofounder will help. It's terribly surprising what goes down outside the confines.

As a QA dev, myself, I run across this occasionally. For a recent bug, the dev couldn't reproduce it, yet I could consistently. The difference: the width the window we were using; he was using the default, I was not. Most of the bugs I run into are not config dependent, so it is always surprising when one is.

As a developer this bugs me too. I once was team lead on a team which had two developers (bad hires) who seemed to believe that it was only their job to write the code, someone else's job to run it and test it. I started putting "and test the code" in the tasks; a team member successfully lobbied our manager that that was another task. So now I had to write 2x as many tasks, and the predictable result happened: the developers who didn't test their own code grabbed all the "write the feature" tasks and banged them out rapidly (easy to do when you don't make sure it works!) The more experienced developers were left to pick up the "and test what you wrote" tasks, which really amounted to rewriting the bad code. Then management said, "Why are you (senior developers) wasting so much time testing code? It generally seems to work and we can always fix it later."

There was just no way to win. I'm glad I don't work in that environment anymore.

Ok, I'm strictly a hobby developer so I don't really have co-workers to go ask for help. Do people really not read error messages? That boggles my mind. How would you ever figure out what went wrong?

I mean, how could anyone ever learn to program well enough to get a job as a professional programmer without knowing to do that?

A lot of programming jobs just need someone who can follow directions, not someone very skilled. It's the digital equivalent putting together IKEA furniture instead of being the person doing all the design work to ensure things fit together and the directions are simple to follow.

The most common way I've seen people try to figure out what went wrong is sprinkling stuff like "console.log("Here1"), console.log("Here2") throughout the code until they figure out which "Here" statement wasn't printed, then they start making random changes to values until the error reflects the changes that they made, then they check stackoverflow, if there aren't any results, they'll paste the error message with no context, having learned nothing in the process. It's pretty common in any field where you can get by knowing "what" to do, vs "why" to do something. I've seen the same thing teaching Linux classes where someone throws up their hands and gives up because they tried to cat a file and it said "error: no such file or directory", but they just saw "error", and decided it was too difficult.

There are certain people that just don't have developed critical thinking skills and will shut down the minute something goes different than expected. I have dealt with a few of those types of people in my career and it is incredibly frustrating. The best thing you can do for them is not to help them in the way they want, by giving them the answer, but by making them do some of the grunt work on their own before they even come to you. I ask a lot of questions about what they are seeing and if they can't answer them then I make them go back until they can. Simple things like "what have you searched for regarding this", "what does the error message say" in order to get them in the habit of actually starting to look into their own issues.

The obvious answer is they don't figure out what went wrong, they tweak the program until the problem goes away for a while.

100% agree.

Likewise, I think adopting a "how can I create a stack trace/error message" mindset is incredibly important.

Can you add a breakpoint to a certain piece of code? Could you add a try/catch statement somewhere to catch the error?

Far too often good engineers do not have an "active" mindset in hunting for stack traces/error messages, instead, they wait for them to fall like manna from heaven.

Raise your hand if you've ever created an insert/update database trigger that explodes when that it sees that one bad value you've been investigating, just so you'll have a traceback that points to the offending code.

(Hopefully only in your development environment.)

I think a lot of the time people are perfectly capable of figuring out the issue on their own, however they ask for help for social reasons. Getting another person involved in the problem is way more fun, and creates a bond between both people.

When you’re messaging me 20 times a day about simple exceptions like “X gem is not installed” (Ruby) and asking me what to do, then it has an opposite offect of creating a bond

For non black and white problems it makes more sense though. Discussing the best approach for something complex, for example.

Timing is important though, you don't want to intrude, interrupt or distract.

I've observed this a few times, too.

This is a good insight. Many a time I've offered a fix to a bug and the response was "how did you figure that out?"

My answer was that I looked at the error message and then, if it was available, scanned the backtrace to figure out which files/method calls were involved. Otherwise (particularly with JS), I set up some breakpoints in the browser to help visualise things better.

I've come across plenty of senior developers who ignore what the machine says. The thing is, most bugs aren't solved through intuition, so approaching the problem as if your gut feeling is completely accurate is going to turn a 10 minute debugging session into something that could last a full day. As, in my experience, it once did.

In general, I agree that juniors tend to skip useful information, but it depends a bit on the technology you are working with. PHP, for example, was known to report the error for the line after the one you forgot the semicolon at or at the line after the last line of the file when a parenthesis was missing somewhere.

While there is a reason why it did so, those are error messages which are quite hard to understand the first few times they occur to you.

Nevertheless, those lousy error message should be exceptions nowadays, and if you are using decent technologies, the chances are much higher, that you just didn't read the error message not careful enough to understand the problem.

My comment is a bit extreme in its tone indeed !

It's just that it's the advice I've given the most by orders of magnitudes, and I'm still amazed (and a bit weary) it's worth even mentioning. And to make it stick, I've removed any nuance of it...

Eventually you'll learn what errors can be ignored, what are useless information, and which ones are sending you down a path that will waste time. But only start skipping and skimming once you've learned what to look for, and always be prepared to toss out the old knowledge when working on a new system.

Also, when you have far too many logs, reading in reverse chronological order works most of the time, but not all the time. Generally the last error you are looking at is the error you want to find and fix, but always consider that sometimes an earlier error that seems unrelated can be the reason a later error is even possible.

This is excellent advice, and I would suggest reading warnings (e.g., compiler warnings) as well – even if they don't indicate a problem, understanding why a warning is thrown is often a very worthwhile exercise.

An addendum to that: Design your error messages. When dealing with exceptions, catch/wrap the exception (e.g. using InnerException in .NET) and add important information if necessary.

You'll be glad you did six months down the line, when the exception actually pops up and you instantly know how to reproduce the bug (perhaps because you know the id of the business object involved).

Edit: Also, use understandable text for error messages. Don't go around talking about threads/sockets etc. unless they happen on that abstraction level. The user should see business-level errors, so they know what happened in the business domain and why ("we don't know why, this shouldn't have happened" is a reasonable answer there, too).

Edit 2: I just thought of Git's "plumbing vs porcelain" metaphor. Abusing it slightly: It's much more pleasant to be notified of an error by a red light instead of standing ankle-deep in sewage. I guess that metaphor breaks down a bit, since toilets more often have the latter than the first :)

I agree that this is one of the most useful things that you can do and one of the most commonly overlooked for whatever reason. I can't underestimate the number of times I've worked with someone who is looking in seemingly random places to solve an error instead of tracing backwards from the error message in front of their face.

Definitely this. Reading logs is a skill.

It's pretty much the same for debugging. I notice the juniors often start to look at where the problem may be. I usually try to first look where it isn't, so I can drill down to where it actually it, in stead of just looking at code and hoping to find what's wrong.

Totally concur, that's very similar to the method I explain to folks when they ask how I go about debugging.

I've always visualized it in my head kind of like a binary search tree, or maybe the bisection method in math for finding roots. I want to think about as little code as possible, so I take steps to cut the problem space down as dramatically and quickly as possible.

Plus, the less I have to think about when debugging the less likely I am to end up with an actual headache.

Also great advice for a senior. Great advice for anyone really.

do not burnout

I know you are young and you feel like you're invincible. I know you can pull an all-nighter and work the next day just fine. We have all been in that situation and believe me, it is gonna take a toll at your performance ... and it could even trigger or help you develop some health issues in your life that can sabotage you down the line.

Realize there's only so much progress one can do in the day. Stop before you are absolutely exhausted and passing out, I know it's sounds tempting but please please do not fall into the trap management or more senior people (that were forced to do this too but didn't learn or are "paying it back" now negatively) to wrest that one last drop of energy. After your X allotted time, even if you are still feeling energized, go spend that energy jogging or something! Work a craft, learn to play an instrument.

Risking to toot my own horn, this might be the single best non-technical advice in this thread.

I can't upvote this enough. Burnout is real and it is horrible to experience, and could possibly derail your career for years. I was fortunate when I experienced burnout in my mid 20's that it didn't derail my career trajectory, but I have seen cases where it has.

This is definitely the #1 thing to focus on as a junior dev. Start to understand your limits. Listen to your body, become conscientious of your emotional state. One of the best junior developers I had the opportunity to mentor was a 35-40 hour per week developer who consistently day in and day out delivered code. He was dependably consistent and eagerly took advice without ego.

Aren't young people allowed to, well, be young though? When you don't go to nightclubs, don't have friends to call at 1am and can't play guitar in your 400sqft apartment with neighbors on all sides of the world's thinnest walls, is it a terrible thing if coding all day and all night on relatively minor problems to make somebody else five figures a week is your primary source of excitement? Does it not beat alcohol and Counter-Strike in the realms of bad things for your health that generate dopamine?

(Totally agree with the advice who have money and relationships though. But none of us start there.)

You should try to do whatever makes you happy. If it makes you happy to give your labor away for free to some large profitable company, then by all means do so. I would personally try to use my time for myself (either to make more money or to do things I enjoy), but it's a personal choice after all. Only you can make that choice.

That said, having balance is usually a good idea. If you have interests indepedent of your work, you will be able to lean on those interests when work isn't going well. This may not seem important now, but some day you may find yourself tired and lonely working late at night without seeing the fruits of those labors and suddenly your stuck with nothing else going on in your life.

I know that (I learned it at 25 though) but I don't regret being 19 and unbalanced. I had fun in the end. Suffering is a universal human experience and not something to be avoided at all costs or anything.

I mean, sometimes we give young people advice and they are super eager to do everything right and use all the lessons the older people learned. I figure, there may be value in learning that particular lesson on one's own and on one's own time.

The recent Tesla news are a good warning bell against never learning it, though. As was in a different way the recession.

> I figure, there may be value in learning that particular lesson on one's own and on one's own time.

I smart man learns from his mistakes. A wise man learns from the mistakes of others. I mean sure I also went through similar unbalanced years as you and I learned from them, but if I could go back and change something I would instill some more wisdom in myself earlier. I don't live regretting that time of my life, but if I had the chance I'd certainly do it differently.

I believe that most of us that 'made it' (past the kickstart/young-ish phase) have experienced burnout at some point, and we know how much it can delay us from making progress...

That's why I think we should at least try to warn our younger friends that all that eagerness to 'make it there' might actually hurt them in the process. Consistency is key and will take you far, because you'll keep on delivering.

Your boss most surely won't remember of your "weekend hero/superstar" phase when you're having a one or two month downtime period because your head isn't right, and your body isn't working okay from all those jolts you've given yourself from your caffeine micro-poisonings. He'll ask "are you gonna keep me those deadlines?" :-)

So yeah, we should leave the young people be young but the more information, the better.

Truer words have never been spoken.

Why is the alternative nightclubs and counter-strike though? Why not, getting a good nights sleep, reading books and lifting weights?

Because you can do the latter relatively easily at any point in your life (pre-senility) unlike the former.

Do what makes you happy, but don’t neglect your health (mental as well as physical) and take breaks/holidays. I spent too much of this year hating computers due to burnout and it’s extremely draining and depressing to have your primary passion leaving you feeling annoyed, frustrated and empty. It’s taken me pretty much all year (most of which I spent out of work) to get to the point where I can work without feeling too bad, but I still struggle to get any code written for passion projects despite having tons of ideas that excite me (until I sit down to work on them). It’s nuch easier to prevent the problems than to fix them after the fact.

In my personal experience, the way to prevent burnout for me is to have other hobbies, to stay physically healthy (especially to get enough sleep, but exercise and diet are super important too), to take plenty of holiday time, and to work on passion projects that are meaningful to you. Working on stuff to make someone else rich isn’t meaningful to me (especially when you see people getting burned by employers again and again — it’s rare that companies will return the favour)

Also, go easy on the coffee. Caffeine is a bad substitute for sleep.

When I was in my early twenties, hungry and looking to prove myself, it was fun for me to stay up all night programming, put in wild hours to get stuff done, lose myself in overly ambitious projects etc. At some point I realized I kept hitting a wall (which was just actually me burning out, but I didn't recognize it at the time) and finding it basically impossible to care or get even the simplest things done for weeks at a time.

My overall productivity was extremely bursty then–herculean efforts followed by barely anything at all. Now, years later, I'm much more defensive of my time, it's far easier to maintain a consistent flow of good work, and I no longer wake up in the middle of the night having had a bad dream about my code crashing.

This resonates for me, particularly the description of falling into bursty-then-herculean-then-barely anything. So what did you do when you were hitting that wall? Myself I've started putting more time the last few years into non-computing hobbies when outside of work. It's a hard decision because that feels like an abandonment of things I used to like to do or of creative things I had high hopes for producing. But it's probably necessary.

I know that taking a vacation is important too, but it's hard to take enough time off when you only get 10 days' a year. And I have a crap immune system so I end up using half of that to cover for when I run out of sick days every winter. (At my last job they started "hemorrhaging" developers because a local startup put out a standing offer to higher people for 20% less pay, but 20 days starting vacation. So many people took them up on it that our branch office dwindled from 12 to 2-3 people and retention of new hires went to the basement as well. The impression we got from management was they'd let the company burn to the ground before making "more vacation" a negotiable, probably because they had a vesting scheme and existing senior employees had worked there 10+ years to earn comparable amounts.) At my now-job I have the option to work 9 hour days and get a day off every other week, which helps make my "real" vacation hours stretch longer but the downside is that 9 hour days are not easy, either.

> Aren't young people allowed to, well, be young though?

Working all-nighters to the point your health starts to suffer is not being young. It's exploitation the likes of which the chapters on the industrial revolution warn us about.

More importantly, we as a society should actively discourage this sort of abuse. It makes no sense to let our health waste away just because a manager wants to boast about a target or a deadline.

If I'm pulling an all-nighter coding, it's sure as hell going to be on my own project. I think that's the context of the convo

The OP wrote:

> "coding all day and all night on relatively minor problems to make somebody else five figures a week"

which makes no sense. Of course if one ever codes outside of the day job one should code for their own project, but that's not what the OP was suggesting.

Oh, I must have missed that. My apologies :)

This doesn't make much sense. You can very well code at night but at least that shouldn't be related to your day job. I'm not sure what you get out of "coding all day and all night on relatively minor problems to make somebody else five figures a week". If you code something for yourself that's the best.

Also, not sure if Counter Strike should be regarded as bad as alcohol, though indeed both might become addictive if careful.

I've found this oft-cited advice of avoiding over work and late nights misplaced if the argument is that you get no net benefit from it, esp if you are young and have the energy. The best work I've done has largely been the product of intense personal focus, and late nights of long deep work sessions. I don't buy the notion that there is no "free lunch" and that pushing yourself always results in "performance debt" -- though it may come at the cost of other things like relationships or personal health. I think being conscious of this, as you said, is the key -- but I don't think you are just given a flat balance of performance and ultimately "pay it back" if you throw yourself into your work in your 20s.

It's certainly possible to go too far but certainly the path to mastery is paved with many hours of practice, often to the sacrifice of other things. It may not make one feel great to consider you can't become Mozart without deep sacrifices and it doesn't make for advice one feels like giving others. I think the best version of this is probably "work really hard but be aware you have limits, and that sometimes it's important to sacrifice performance and skills development in the name of a balanced life and good health." I don't like framings that could be interpreted to mean if you hustle or don't hustle you'll get the same result, since "there is only so much you can do in a day." Knowing there is a real tradeoff and "know thyself" is a better pov imho.

People vastly underestimate how easy it is to burn yourself out and how long or difficult it can be to recognize you've done it. Solid advice. I'd tack on finding a mentor who pushes back on you and has reasonable work/life balance expectations.

I sometimes find people that have mentors that have crappy work/life balance and they look up to them like they're some kind of superhumans.

It's just like in japan when someone falls over a heap of work on premises at late hours, instead of lazy they think the guy is a 'trooper' for staying in for such a long time ("must be a strong person").

This has to stop.

My boss at my first gig was like that. Would always praise anyone who worked late or rushed in there to put out fires outside of work hours, he wasn't very interested in preventing fires but always first in line to play the hero role.

And on top of that he was severely dyslectic. I don't know, I feel like he would have made a better fire fighter.

Long story short, it took me two years to run into the wall like a freight train. This was 20 years ago, to this day I have serious issues with phone signals and stress in general. First sign of trouble and I simply shut down, can't do it any more.

Second that!

Also maybe you are not young. Maybe this isn't the first sort of work you've done. If not you, then maybe someone else reading and wondering the same thing.

Try to be consistent and avoid plateauing for long stretches. Consistency will take you far. Maybe you make some sacrifices of other hobbies and uses of time to get some early traction with your skills, but be intentional about doing this and don't put the other things that nourish you on hold forever.

Embrace the beginner's mind that comes easy to you now, remember it so you can cultivate it again more easily when things inevitably feel a little dull or tedious down the road.

This, plus do only 9-5 jobs. Do not work longer than 40hrs / week.

I think it can be okay to occasionally crunch for a few days at the end of a project. But yeah, you need to establish your boundaries now, to yourself at least. Do your homework, ask about expected overtime in the interview, and don't accept any offers that will expect 50+ hours/week on a regular basis.

It’s inportant to recognise that all overtime has a cost (both to you and the business). If I crunch this week, I typically lose more than I gained next week. I believe that Peopleware has a section on this.

Basically this means that crunch is fine to get out of a pinch, as long as it’s very infrequent and the cost is allowed for. Eg if there is an important deadline due this week, by all means, crunch to meet it, but next week is going to be unproductive and these tight deadlines cannot he a regular thing.

Sometimes I worry that I've never once felt a desire to do this.

Then you are very lucky to not have had it foisted onto you. I've been on way too many death march projects. You can see the train wreck coming, you can make all the warnings and signals, but you can still end up in the middle of them, working stupid hours doing things that don't make sense and lead to burnout.

This. But as further justification, some of the worst and dumbest bugs I've introduced in my career were late at night when I was exhausted and trying to push through.

Couldn't disagree more. Burnout sucks... and the crash was terrible, but the things I accomplished leading up to my burnouts were the best work I've done in my life. Here's what I would say: DO IT FOR YOU, not for someone else, not for a company... do it for yourself and what you want to accomplish in your life

I don't think anyone that's been truly burnt out would say something so stupid. It feels like a constant handicap on my skills and abilities. I don't think I'll ever perform to the standard that I did before, and this feels like a great shame given I have my career ahead of me, rather than behind me.

First, pretty sure the concept of "burnout" is a subjective attribution to a very physical, prolonged, exposure to overworking... so its really tough to say who has or hasn't been burned out.

Second, while I appreciate that you are going through hardship, I don't think thats fair to discount a 16 month stint working an average of 74 hours a week. Including a 45 day in a row, and 31 day in a row period. I burned myself to a crisp for a very real goal, and am happy I hit that goal. Of course, The months following were a disaster, and I don't think I actually snapped out of it till 1-2 years later. But I did snap out of it. (Note: I wasn't working in software either...)

Third, you can get through it. Burnout is physical AND mental... the problem is that people think that its primarily mental. If you are able to get past this incident, you will be stronger because you will know what your limits are. I'm not saying its easy... but if you ended up in this situation by working on something that you are truly proud of, or that you accomplished something that you wanted your entire life- then for me, its worth it.

Lastly, if you need help, or are having a tough time hit me up. I don't know what help I can be, but I can try to help you get through it :)

Or, you know, accomplish what you want without burnout. Almost always possible, for a programmer at least.

Learn about the business side of the company. It helps tremendously if you understand how management/sales/marketing/etc think.

Don't follow your passion. Passion will come if your work is meaningful, you are competent and respected for it. So instead work on your competency in whatever field. Leave if the environment will never respect you anyways.

All software problems can be solved if you work on it long enough. Do not give up just because StackOverflow does not have the answer.

A really good question to ask for a task is "How do you know you are done?" It might prompt to clarify requirements. It might prompt you to make things more measurable or testable. It makes you think about implicit things like following code guidelines. It makes you better at estimating time.

Never assume anybody is stupid. Instead, figure out how these intelligent, well-intentioned and experienced people have come to a decision which is stupid now.

Do not just fix symptoms but (at least try to) fix the root problem.

Participate in discussions instead of just listening. If you are wrong, then you learned something at least.

Sit together with experienced developers. Watch how they use their tools.

> Never assume anybody is stupid. Instead, figure out how these intelligent, well-intentioned and experienced people have come to a decision which is stupid now.

On that note, don't assume that any particular existing piece of code you find is somehow "blessed". Do assume that everyone, yourself included is a total idiot and capable of writing fallible code, and in every avenue and every respect of life, assume that there _may_ be obvious, ingenious, simple/scalable/efficient/elegant solutions that have been overlooked leaving open possibility of a better way. Never be annoying about it though.

I had the opposite problem when I was junior: I believed most existing code was crap because “it’s not how I would have done it” and had trouble resisting the urge to rewrite everything. Learning to live with and thrive with legacy code is a great skill.

I was that way as well, but all the juniors I encounter now are the other way around.

But beware of Chesterton's Fence (which is really what GP suggests - understand the history of something before attempting to reform it).


> A really good question to ask for a task is "How do you know you are done?"

One of the more valuable things I learned in product management is defining what success looks like. It's tempting to just put a product out there/work on something, and think it'll pan out, and you'll know when you're done.

> "Never assume anybody is stupid."

OMG THIS. This is one of the best things anyone can learn.

>Don't follow your passion. Passion will come if your work is meaningful, you are competent and respected for it.

Ehh, everyone starts at zero and you need passion (or otherwise some form of goal/discipline) to become competent to begin with. Nothing wrong with using passion to follow a goal. Just don't be place all your eggs in one basket; it's not the end of the world if you don't instantly reach your dream goal/salary/life choices.

These are a lot of the things I would want to say if I had near any authority on the topic.

>Participate in discussions instead of just listening. If you are wrong, then you learned something at least.

I feel being a part of the discourse is especially important and is still something I'm learning to do. There are a few times I wanted to contribute but believed what I had to say was already obvious to everyone else or to at least the people with more expertise and it turned out not being the case. Still, consider choosing your fights and

>Leave if the environment will never respect you anyways.

On the slightly more negative side: everything management tells you that's not in an email will have "never happened" when it's convenient.

When you have a conversation with anyone where you think a plan was verbally agreed on, before doing anything your first action is to go back to your desk, write it in an email, send it to them as confirmation and find at least 1 other person, ideally in your reporting line, which you can cc it too.

Because it doesn't take an actively malicious manager to screw you over - it takes literally anyone who suddenly needs to change history to their own seniors for it to fall on you, the underling.

EDIT: And the friendlier or more casual someone is, the more important this becomes.

And it doesn't even have to be any malice. People forget things, (re)interpret things until a thing is no more, or just misunderstand them from the get-go.

This is a good advice, glad to see it. While it won't be helping you much to get through your day, it'll count where and when it matters a lot.

I think you're underselling this. You're right that malice is relatively rare. Ambiguity, however, is the norm.

For example, say you have a quick discussion and decide you will do task X and your colleague will do related task Y. You nod and head off to work. For most people, this feels like a commitment but if they haven't explicitly promised a deadline then there's no assumption of when it'll be done. So it might actually never be done, and whatever commitment has been made is super weak.

But then: you write an email "Thanks for the chat. I'll do X this week and you'll follow up with Y in time to ship by Thursday the 11th". By getting explicit about the timing you're really asking them, in a specific but not confrontational way, to seriously consider the timing portion of the implied commitment. Maybe they're super swamped with something else and assumed you'd be OK waiting? Maybe the work is more complicated than you realized and will take longer?

For most people, in most work environments, these kinds of ambiguous commitments are more common than clear, thoughtful ones. But anyone in an interaction can help steer it toward clearer commitments, and this is frequently very valuable. It's valuable to you because you know what you can really expect from others (or if they let you down, you know the difference between them failing to magically read your mind vs. do what they promised). It's valuable to others (as long as you're not a jerk about it) because it'll help clarify misunderstandings before they become a bigger problem.

Yea this whole thread should be upvoted higher. Document everything. I’ve gotten into the habit of documenting everything I’ve worked on at the end of each week, just so I have a record. It comes in handy at review time when you’re asked to write about your accomplishments or whatever other hoops management has you jump through to justify your existence.

Bingo. Documenting discussions should be about better communication and understanding.

Feeling that things need to be emailed because of malicious actors is not healthy.

I agree with actions but not the reasons.

You should get confirmation in writing to verify your understanding and protect against a non malicious, honest manager who has a lot of things on his plate and may honestly forget the details of a conversation.

But, if you hope written communication will help you as a CYA move if you have a conflict with your manager and your manager is being purposefully underhanded, that rarely works.

The organizations primary job is to protect the organization. Unless you’re a special snowflake, your manager’s manager or your HR department will always take the side of a manager.

That’s just like getting a PIP. Once you get one, learn from your mistakes and take an honest self assessment - but do it at another job. If you interview while having a job, it’s much easier than trying to interview if you got fired.

> On the slightly more negative side: everything management tells you that's not in an email will have "never happened" when it's convenient.

This brings us to two very important points:

1. Never delete any email. Only archive. Search does wonders to cover your ass.

2. Never use company email for anything personal because you are never going delete any email and you are not the only person who can search your company email.

Agreed in general, although I do delete unimportant email.

Also, make a local archive. When laid off you will lose access to company email before they notify you.

Documenting what you have been told verbally is not a negative act. People forget what they have said all the time!

Generating a followup email is stating your understanding and interpretation of a verbal conversation. Verbal communication is full of intricacies. Especially when communicating things like priorities.

Why did you spend so much time on that feature and not this one I think is more important?

Why did't you tell me that "minor" feature A was going to mean that this more important feature B IMO was not going to get done in time?

I have never had to do this nor seen anything like this behavior in my 6 years of work in the industry. This sounds incredibly in bad faith, and I would probably take it as a signal to go job search for a better work environment if I witnessed this in my day to day.

Months ago, I estimated a feature to take 3 weeks to build. A couple of months later, deadline nearing, a new developer was asked how much time it would cost to build and they told the product owner that it would take about 3 weeks. The product owner then looked at me, annoyed, telling me that nobody ever told them that it would take that long to build. I was really happy that I could show them the initial estimate I gave them.

If you haven't experienced this ever, definitely be extremely grateful. Also, when you switch jobs, beware that past experiences are no guarantees.

I think that's naive. The parent comment phrases it a bit more cynically than I would have, but it's in everyone's best interests to casually document plans and intentions. People forget, people misremember, people promise things without fully thinking through the implications in the moment. A friendly email restating the key points of a discussion is conscientious, professional, and keeps everyone on the same page.

I'd personally be very suspicious of anyone who tells you not to do that. There is literally no downside unless you're trying to hide something.

My response to that would be that if someone remembers differently, they should treat their coworkers with respect and give them the benefit of the doubt if there is no reason why anyone should be skeptical. That is not a good work dynamic if your coworkers are not doing that, and is cause enough for me to start job searching.

If there is reason to believe that there are disagreements in actions to be taken, then messaging everyone to get on the same page is ok. If someone is actively throwing someone under the bus unceremoniously & quickly, then one should prepare an exit strategy & a strategy for working around the problematic coworker as a cautionary step because the spinner could potentially stop at oneself. If it is more than one problematic coworker, then the exit strategy approach becomes increasingly pertinent.

I think it is self-defeating to do other than this approach in general, and far from naive.

I don't want to assume anything about your work history, but I have worked at 2 fortune 500 companies, and I can absolutely say that if its not in writing it didn't happen.

Perhaps these companies were outliers, and I don't think anything I experience was a result of malice. However, when the higher ups are looking for answers, middle management tends to put blame on the developers. I can't tell you how many times I had to dig up old email chains to essentially prove what was communicated. People forget, people misremember, and people will fabricate to avoid repercussions. I have found this to be a universal truth of business, so I can see why someone would say your comment is naive.

Also like the comment above yours states, there is literally no downside to re-affirming the discussed points. I've had instances where once things were put in writing, my manager noticed something that wasn't clear and we were able to circumvent issues.

You are still focusing too much on the cynical/mistrustful motivation. Positive, professional intentions indicate the same action.

If you think documenting plans and discussions is "self-defeating", I really don't know what to tell you.

As others have stated, it’s not about malice, but rather about miscommunication, misunderstanding or simply forgetfulness.

It has happened many many times that I thought I was clear on a thing and that everyone was on the same page to later realise that some of us completely misunderstood what was discussed or agreed. Sending a summary email afterwards helps make sure that everyone came away with the same conclusions.

I’ve also found it extremely common that people simply forget things, or parts of things. I’ve had bosses who forgot that they asked for a change or feature or task to be completed. I’ve had bosses who forgot that they agreed to change a requirement or that something isn’t needed or important. I’ve forgotten that I said I’d get something done. I’ve had coworkers forget that they were supposed to do certain tasks.

By sending a quick “here’s what we agreed to” email avoids all of these issues, or, at least, let’s you point at it later if someone questions it later.

Basically, it’s a good idea to keep a log of decisions that were made.

I'm probably over-selling malicious - other posters have covered the mundane reasons better.

But anytime I've suddenly been stuck feeling "wait how was I doing the wrong thing?" the overwhelming reason has been traceable to the fact I can't point to any specific bits of correspondence which justify why I was doing something a particular way because it was all ephemeral.

For me, it's a workplace confidence builder - there's not a lot of light between a manager forgetting something you said, or hearing something different, from your perspective when the question posed is "why did you do a thing?". In those moments, being able to point to specific records of correspondence means the discussion now has a concrete starting point - even if it's going to turn out you absolutely misinterpreted what was asked.

It's hard for people to have recall over events and (again not always malicious) what one person may consider a "big deal" to have done (or not done) will influence whether they remember and how they remember it. I've been pulled through changes I was opposed to (in my opinion, it made less sense to make the change) and eventually conceded to the change. 1.5 years later everybody (both those who agreed with me at the time and those who disagreed) was all about changing it again (back to the way it was). I had the email conversations and remembered what previously happened and was able to (re-)inform people about why the decision had been made (no, I did not want to revert all the work I did even if I still thought we shouldn't have made the change).

Not everybody has access to a better work environment...

Thank you for writing this. I came here to say the same. It is vitally important that people just starting out learn this and make it habit.

Also, if you have an important decision to make, something that if it goes wrong it would be pretty bad, don't make that decision unilaterally. Partner with your direct report. Get them to sign off on it.

I understand a lot of people here have come from fortunate working relationships—

but in many fields things can be more competitive, or you can have new entries into your environment that will unexpected changes in the dynamic.

This is why early on many senior staffers most places I've worked lead with "COYA" when mentoring younger staffers. It's saved me more than once from bad actors.

The importance of this is amplified at larger corporations. Great advice.

I've screwed myself multiple times by not being sufficiently anal with the followup emails.

I've also screwed myself multiple times when I did.

It's hard to know when to do it.

Instead of continuously second guessing myself, I've settled on preferring trust-based relationships.

Alas, I've only experienced that twice. It was heaven.

Anything short of that is torture. I hate the "Guess what I'm thinking?!" game.

TL;DR: Miscommunication is the norm. Learn to persevere.

Treat people with respect.

Sleep well.

Take care of your body and your mental health.

Try to turn any feelings of inadequacy or imposter syndrome into energy to push yourself forward and increase your skills and knowledge. We've all been there... multiple times.

Learn to code fearlessly: Are you being asked to run queries on a production box? Ask if you can get a user with read-only permissions. Change crusty old code? Maybe put a quick test harness around it.

If you're stuck when debugging a problem, think about all the assumptions you're making, and then test each one of them, no matter how obvious.

Understand that code is often ugly and weird for a reason other than incompetence. Code quality tends to be a function of time, requirements, experience, and skill.

This my favorite comment on this thread. Coding fearlessly is such a privilege/skill - makes a world of difference.

It's hard won.

When I manage to get a team to create a code base with good tests it turns out that it's easy to change and resilient in the face of sudden requests for features.

A poor test infrastructure doesn't do this, building a good infrastructure is a skilled task. But worth it!

Love the last point. If you can internalize and truly understand this as a junior developer you will stand out among your peers, since many people can go through a whole career without ever learning to always assume the original authors of a piece of code were competent and well-intentioned.

These are golden rules to live by!

Don't stress about not being good enough when you see other people's work. People show off their end result and not the hundreds of broken iterations it took to get there. You can build exactly the same stuff with a bit of effort, learning and time.

Corollary: if someone posts "my first X" to a big public site like reddit or HN, it is almost certainly not literally their first X; it's just the first one they felt comfortable enough to exhibit publicly.

(At least, that's what I tell myself...)

I've been coding professionally for a decade and I'm pretty darn good at it, but I still have to tell myself this.

This same thing relates to most things in life, you never see the struggle other people went through to get where they are.


Read at least HackerNews and possibly some other tech news site regularly. And then make sure to not get too caught up in the hype for new stuff.

As someone working in technology, you are going to be learning new stuff continually (or your usefulness is going to diminish over time). By keeping up to date with tech news, you get a lot of context for what people are using, what's coming down the pipe etc. You may end up experimenting with stuff and then you'll be ahead of all your colleagues. It broadens your knowledge, and if you have to deal with clients it means you will usually know what they're talking about.

There's a few pitfalls to watch out for though. HN is great, but it is still an echochamber that can be focused on web and related tech. I was mostly an embedded software engineer for years and found comments like 'does anyone even use C anymore' hilarious (yes, see Linux kernel, device drivers, and your washing machine for details). It can also be very easy to end up wanting to push for the 'shiny new thing' too early. I tinkered with Rust from very early on, but it's only in the last 6 months or so that I'd suggest it is ready for use in most companies (depending on application area). Javascript frameworks suffer this problem particularly badly. Mature beats shiny 9 times out of 10 - running into a problem that 100 people have met before and posted about on StackOverflow and your tool caters for, is much better than being the first person to encounter said problem.

> Read at least HackerNews and possibly some other tech news site regularly. And then make sure to not get too caught up in the hype for new stuff.

Interesting because I advise the exact opposite: do not waste time reading HN, just find one thing that is interesting and master it. Then repeat.

As much as I like HN there is a lot of noise here. Novice mind can easily fall into a trap looking for signal here.

I've gotten a lot of value from reading HN. I've also wasted a lot of time. It helps to develop a personal filter. Mine is

* Avoid headlines that make me angry, unless the news is really important. The discussion is never worthwhile, don't even bother.

* WSJ, Bloomberg, and WaPo won't let me read articles with w3m, so I skip the article. If the topic is tremendously interesting, I'll check the comments.

* TED and nautil.us are the information verison of empty calories. I've never gained any long term benefit from reading them.

* Javascript framework churn is intense. It's not worth trying to keep up with the details unless you do web development. If, like me, you don't, it's still worth reading the headlines to keep abreast of what frameworks are popular, what paradigms they embody, and who's pushing them. This changes every six months or so.

* It's always worth scanning the comments in threads about programming languages. There are some really interesting people who sometimes jump into those threads and blow your mind.

* Know your prejudices and look for information that challenges them. My prejudices are that I think Windows is lame, that MacOS is infuriating, that Javascript is terrible, that vim is better than emacs, and emacs is better than IDEs, and object orientation is a failed paradigm. So I look out for articles that have a different point of view. I've learned that Microsoft has some really interesting technology, that Apple is infuriating even to its own users but it doesn't matter because they're sitting on the world's biggest pile of dollar bills, that Javascript is usually unnecessary but occasionally useful, that kakoune is even better than vim, and that nobody agrees about what object orientation even is.

I eschewed QBasic early on because it wasn't "real" or it was derived from Basic. This was a mistake.

I spent a long time trying to become good at C++. This was also a mistake.

I ignored Python for a good 2 years because of indentation. Again, a huge mistake.

Great suggestion on anger inducing articles/comment sections. I was just thinking it would be nice to do sentiment analysis and incorporate the emotional vector into both the dynamic rules and the layout. At least put a badge on the discussion so I can know to stay away.

I'm curious - could you elaborate on your mistake regarding spending too much time on C++?

It was too large and too complex for the kinds of things I needed to do. I over focused on getting better with my tools rather than working on domain problems.

Since it has affordances for speed, it encourages one to make fast code, but this is rarely needed. Making fast code is a trap.

Trying to become good or very good at something also puts you in direct competition with others doing the same thing. I did not have time to compete, so it wasn't a big differentiator for me.

C++ helped me learn when do give up, and when to refocus my attention in areas where I can have greater impact. I wish I was a little more technically and philosophically mature before I undertook C++. Having concrete goals is a huge clarifier and allows one to judge something with a much better light.

> WSJ, Bloomberg, and WaPo won't let me read articles with w3m

w3m, nice! I tried lynx, w3m, eww (emacs) lately, and liked w3m the most, but found it terribly slow on many sites. In particular GitHub. Just measured 12 seconds for loading my Profile. lynx takes 5s. Opera takes 2s.

Do you have similar experiences?

Yup, it's slow for me too. I like it anyway. I want to like links, which is way faster, but w3m is just so simple. If I had to guess, I'd say it's because w3m doesn't support gzip compression.

> Avoid headlines that make me angry, unless the news is really important. The discussion is never worthwhile, don't even bother.

> Know your prejudices and look for information that challenges them.

How do you prevent the two of these from coming into conflict?

Headlines that make you angry are designed to make you angry. It's not about information that challenges your prejudices, it's about being intentionally provocative. I'm not interested in being baited.

"object orientation is a failed paradigm"

uh... wtf?

I know my prejudices. I recognize that a lot of people think OO is just dandy, and I'm on the lookout for a good argument in its favor. I'm open to the possibility that the reason I think OO doesn't work is that I don't understand it well enough. Maybe somebody out there will explain encapsulation in a way that doesn't make hidden mutable state seem like a nightmare. Maybe somebody's got a blog post that explains why inheritance only looks like it makes spaghetti code, but actually I can safely ignore the dragons lurking three levels up the hierarchy. Maybe there's some piece of OO code out there that embodies a beautiful solution to a problem I've been struggling with. If those things are out there, they're going to get posted to HN eventually.

Here's an explanation from Casey Muratori: https://youtu.be/GKYCA3UsmrU?t=4m50s

See also Mike Acton (Engine Director @ Insomniac Games): https://www.youtube.com/watch?v=rX0ItVEVjHc

You aren't going to get a lot of support for OO in places where it isn't really necessary like games, and especially games with single developers. At that point the management of data is on the developer. Essentially one is saying that if they fuck up the data, that's on them.

OO is handy in enterprise software where there are lots of developers who may not understand why things are the way they are, they just need to do something. In big, complex systems where a lot of things are going on, if you give someone a noose, they will hang themselves. OO can protect data from some (of course not all) unintended consequences.

> there is a lot of noise here

This is true. However, much of what I know about how software development can work, I've learned from reading HN. I've learned loads about cloud, containers, micro services, project problems, etc. This helps me understand all the discussions around me while I was a junior and allowed me to successfully lead development of a SaaS product. If I just focused on learning a single thing, I wouldn't have been able to grasp all the other stuff that is necessary to actually build a product from scratch.

The advice elsewhere in this thread about focusing on one stack and getting good at it is definitely true.

Broadening your knowledge to be aware of other stuff is also useful though. The most useful people are those who understand how multiple things work and fit together.

> and master it

Mastering something is expensive, one should have multiple good justifications for doing so.

Deep familiarity is what people usually need, beyond exposure, but below mastery/trial by fire.

Along the lines of reading HackerNews, read TheDailyWTF.com on occasion. It's fun and entertaining, but that's not why I'm recommending it. A lot of the bad code, bad error messages, bad designs, etc. were not necessarily done by someone _incompetent_, but rather people who are simply inexperienced in one way or another, or were in a rush to meet a deadline and weren't careful.

(At a former company, working in a team full of very strong engineers, we still found one dialog box of ours end up on that site once, and the issue it demonstrated led us to a bug in the code.)

If you start seeing things on there that look like something you'd have done, don't beat yourself up over it, but learn why those are WTFs and re-evaluate how you're writing code/designing software.

> Read at least HackerNews and possibly some other tech news site regularly.

Just be warned that places like this are the worst kind of habit-forming variable-reward site. Worse than Facebook, really. Every now and then you'll find here something that will tremendously improve your worldview, programming skill, or propel your career forward. You might then find yourself using this as a justification for wasting disproportionate amount of time on reading random things, instead of doing.

(Yes, I'm very much stuck in that trap right now.)

Do you have any recommendations for news sites that focus on embedded software? I've recently started a career focusing on embedded tech but most of the interesting stuff I've come across online seems to be confined to blogs from the 90's/00's

My favorite, along with about everyone else in the office, is https://hackaday.com

Save 25X your annual spending and you can retire. If you invest to earn 7%/yr (on avg), you can withdraw 4% forever.

Read the book The Simple Path to Wealth, or the basics in this blog post.


Sound advice, but you have lots of options. Many countries have some sort of government retirement that you can live on (at a greatly reduced lifestyle). You have a family history to guide you as to how long you will live. You have hobbies and interests that cost money: you can do the hobbies less, save more, and retire early; or you can do the hobbies more, save less and work longer. It is about tradeoffs.

I have a friend with a genetic defect - unless there is a major medical advance he will be dead in about 15 years at 55. He doesn't need as much saved up to retire.

I have a friend who couldn't afford to retire until 75. He really enjoyed his younger life doing things that his body isn't able to do now. Perhaps this is the right decision for you.

I knew someone who saved a lot of money and then unexpectedly died 2 years after he retired. On hindsight he shouldn't have saved as much.

The only wrong answer is not making the best decision you can about.

Could anyone explain this a little for me, please?

Does this mean you save 93% of your income and only use 7%?

From the website, there is a graph that shows how many years you supposedly have to save for retirement but it does not take into account the actual amount you make.

As a "junior" dev, if you save 97% of X peanuts you still have peanuts.

The 7% is referring to the rate of return on your investments. He is making the assumption that if you invest $100 in the stock market on January 1, then on Dec 31 your account will have $107 in it. This assumption is an average over many years.

There is a common rule of thumb in the investing world that you can safely remove 4% a year from your investments and they will continue to grow. (7% return minus 4% withdrawals means you have 3% more in the account each year)

It doesn't matter what your lifestyle is. If you are a junior developer who makes 80k a year and spends 50k a year, then you should save 25x50k=1.25mil and then you no longer have to work for a living. This process will take years or decades.

Quick question. Is the 80k an example you threw out, or a reasonable amount for a junior dev to make? Specifically for a a mid-sized company in the States, outside of Silicon Valley.

Currently working as a junior dev and the senior devs feel I'm making less than I should be. Which is much less than that 80k. The only caveat being that my employer is also paying for part of my tuition (up to a max of $5000 a year). Previously, this seemed like a decent increase with what I was making, but adding that 5k to my wage and I'm still nowhere near the 80k.

I'm throwing out this comment as it seems like it would be beneficial to other junior devs to have a ballpark amount to shoot for. Obviously other factors play into this (e.g. healthcare, location, etc). This just seems like a decent play to ask without breaking taboo with local devs.

It's obviously location dependent, but in most any booming US city (Seattle, Denver, Austin, etc.) a junior dev should be making at least 80k unless they are truly green.

This is completely dependent on your location and the size of the company. E.g., when I recently looked into the stats for Germany, the average annual income for a developer in a small to medium-sized company is ~48k€ (~55k$), which is a long way from the 80k figure.

Google around, check Glassdoor for dev jobs in your city. If you feel that you're under paid bring it up at your next review. If they refuse to give you more start to look for other jobs.

The 4% number comes from 7% mean return divided by 3% mean inflation. If you take out 4%, your investment won't grow, but remain constant, keeping pace with inflation. Eventually, you will hit an off year and stumble. The probability of that per year is low enough that it is reasonable to take out 4% every year of a less than 30-year retirement.

Perpetual income, or an early retirement, therefore takes less out every year, such as 3%, and has that 1% growth buffer to smooth over the down phases of the business cycle. You can also avoid spending on life insurance, and just draw up a last will document.

Divide your target income by your withdrawal rate, and that's your target nest egg. To get $50k/year, you need $1.7 million to retire early (3%), but $1.25 million is just fine if you clock out at 65 years old (4%).

If you assume a mean 4% growth in excess of inflation, and your income and expenses rise with inflation, you can hit your target making $80k and spending $50k in just 30 short years. If you want to retire in less than 40 years of working, you'll need to spend less than 73% of what you earn (or earn 37% more than what you spend). Spend only 66%, you can do it in 34. Spend only 50%, and you're working just 22 years. Cutting your expenses can only get you so far, though. You'll have to keep that level of consumption down for the rest of your life. At some point, there's nothing left to cut, and you simply have to earn more if you want to retire. Also, you are likely to earn less earlier in your career, where the compound interest counts for more.

So this is my advice: invest at least 25% of your net income--or more, if you use it to pay off debts--before you buy anything else. When you get raises, don't spend more than 75% of them on your living expenses. Pay your future-self first. By the time you become them, you'll be very thankful for the contributions of your past-self.

You save 25 times your annual salary (or savings rate depending on understanding and frugalness). With 25 times your annual salary you should be able to comfortably retire.

It means calculate what you spend annually, and save until you have 25x that amount.

Maybe I'm misunderstanding the math. Are you suggesting that you spend only 1/26 of your after tax income, and save the hypothetical remaining 25/26?

The goal is just to get to 25x your annual spending. Once you're there if you earn 7% interest and only spend 4% (what you'd normally spend in a year), you've now not only spend no money (only a piece of the interest) and that extra 3% left over accounts for inflation. So you build a pool for 25 years of spending, then just coast on that for the rest of your life.

The key is to realize that it's not your earnings, but your spending, so it would behoove one to get that spending as small as possible to get to coasting more quickly.

The math works out in one of those "assuming a spherical cow" senses. It doesn't account for a market downtown for any length of time, nor a required change in spending habits (illness, emergency).

...required change in spending habits (illness, emergency, inflation)

The extra 3% interest being earned that you're not spending (remember the goal is spending 4 of the 7% of interest ) SHOULD cover inflation. Hopefully. I'm not the sort to bet on that though.

He's saying if my expenses are $30,000 a year I need to save up $750,000 and I can retire.

I advise junior developers that there are primarily two difference between a junior and senior developer:

1) A senior developer is unafraid of not knowing things. When we join a new team or company, we're as lost as any junior developer joining them team. We ask as many questions as necessary to get our work done effectively, without shame or fear of looking foolish for not knowing things already. We are good at searching through unfamiliar codebases to figure out how they work.

2) A senior developer (or any productive person) is good at saying no. People will ask for more of your time than you can spare. You can gently but firmly say no, direct people elsewhere (delegate), or ask people to discuss with your manager whether more of your time can be allocated to help them.

I would argue willingness to say no is what separates junior from senior.

In my experience it actually leads to Juniors being abused a lot of times being given dumb projects someone should have said no to. Then code review rolls around and the seniors are like “what is this” and there’s a dumb fight. Lol. Maybe that’s just the places I’ve worked.

I don't think you're the only one who has experienced this; we hired a couple of new grad programmers recently and they've really been put through the ringer. Not necessarily on dumb projects, but projects that one might categorize as urgent but not important.

Your first point is something I've seen a lot of and experienced myself too when I was new. I think it can be a big psychological barrier to learning more and generally being happier/more confident.

I wrote up something about it a while back: http://zalberico.com/essay/2017/02/21/asking-questions.html

Try to sleep 8 to 9 hours every day. In this JRE podcast [0], Matthew Walker, a sleep expert, claimed that sleeping poorly can decrease your performance by 30%.

Strive to maintain a good work-life balance. Burnout sucks. Your health and family are more important than work. A workplace that doesn't consider this to be the case is likely to be toxic.

As for actual software development advice... Beware blanket statements. They can help you develop a low-resolution model so you don't suffer from paralysis, but real-world problems tend to be complex and messy.

Here's an example: if you were building a traditional web app, many software engineers would probably suggest using something like PostgreSQL. That doesn't mean other database technologies don't have their place. However, PostgreSQL is able to adequately serve a large category of problems with relative ease, so it often makes for a sensible starting point. Once you become more familiarized with that domain you'll develop a higher-resolution model and you can begin to evaluate other technologies more effectively. Much of software engineering is about figuring out what tradeoffs to make.

Another example in traditional web apps is using cookies for auth. Using cookies for this purpose is well documented and pretty much supported everywhere. There's plenty of known problems with using cookies for this purpose, but the alternatives also have their own set of issues to deal with.

My final example: testing. Testing your code is great and it can be very useful, especially when refactoring or developing new features. But going for 100% code coverage is usually more trouble than it's worth. It's also very easy to end up writing a bunch of useless tests. You want to focus on the actual problem and not waste anyone's time.

[0] https://www.youtube.com/watch?v=pwaWilO_Pig

> Strive to maintain a good work-life balance. Burnout sucks. Your health and family are more important than work. A workplace that doesn't consider this to be the case is likely to be toxic.

Good advice.

It's likely burnout will really change you for the rest of your life if you don't react early enough.

It's a bit sad when you realize you'll never again be that guy you grew up and identifies as. But you also have to realize that was a person with habits that wasn't sustainable and now you have to live with that.

I'm currently in the process of changing careers into software development. I have a family of 5, a full-time non-tech job, and I just landed my first part-time coding job.

I definitely don't want to burnout, but I also know that I will need to work very hard for a short period of time until I can exit my current full time job and secure a full time software development position.

Do you have any advice on how to strike a balance between working very hard and knowing when you're burning out?

Realize almost everyone suffers from Impostor Syndrome from time to time.

Read a lot of code, not just code in the projects you work on, but reference/framework source code, open source. Perhaps even ask a subreddit for the language/tool about good examples to learn from.

Realize that data is more important that code for the most part. So treat data like it's precious. That's one part of why I feel relation databases are better than document/object stores. I suppose this is up for debate.

Learn to say No. It's mutual respect to say No so the one asking has a chance to ask someone else. If you instead say Yes to too much and can't deliver too close to their deadline you might screw up other people's time plans.

Outside work: Avoid eating junk food more than 1-2 times per week. Keep your weight. Go to the gym or run. Take the bike or walk to work. Sleep at least 6+ hours a day. Limit work to 40 hours/week. It's better to do 40 fresh hours than 50+ zombie hours.

"Realize that data is more important that code for the most part. So treat data like it's precious." This is excellent advice.

Ignore the bullshit.

Languages are tools, and you are a craftsman (or woman). In the same vein, a carpenter doesn’t scoff at using a wide variety of tools and of course has favorites but doesn’t get caught up in them.

Frameworks will come and go, understand how they work under the hood. Understand how Node works, aka V8 engine + C++. Understand why React is so popular but also understand it’ll pass in time as well.

Most of all, just find what you enjoy in programming. If you don’t like architecture that’s totally cool. If you love writing middle tier software, that’s cool. If you like being full stack, totally fine. There’s plenty of jobs in each area so spend time finding what you like.

And understanding how different technologies work will help you build expertise in future ones more easily. Technologies are not usually born out of thin air, they inherit approaches from earlier ones.

I admit this is more of a laundry list than a single advice — as you are looking for the most important advice — I’ll nevertheless list them down. Roughly ordered by importance :-)

* You are expected to manage your career and growth. Don’t rely on or expect your manager or someone else to do that for you. You’ll get lots of good advises around how to grow in your career. It essentially boils down to taking initiative and driving those to closure.

* Understand the product end-to-end as an end-user. All the use cases, all the flows.

* Understand the business model, how it relates to the product and how that product (or part of it) in turn relates to what your team and you are working on. This is much harder than it sounds which is why you need to relentlessly pursue this. The code base you are working on has an abundant of domain knowledge and architectural decisions built into it. Build a mental model of both that domain knowledge as well that architecture. You will rarely find those documented so you need to put in a lot of effort to know all the use cases and relate them to control and data flows. Trace different requests through the system, use whatever tools that are at your disposal (debugger, logs, metrics etc.,). This mental model will really help you accurately estimate feature requests.

* Help those around you in whatever way you can. Treat all the functions (HR, finance, marketing etc.,) with equal respect. Get to know them, what they do on a daily basis, their pain points. If not to help them then at least to empathize with them.

* Actively look out for inefficiencies (e.g., build taking 20+ minutes, broken unit tests, chronic production issues) and take time out to fix them. Even if no-one appreciates this you will have at least a feeling of fulfillment of having achieved something valuable to the business/company. In the process, you will have learned something new.

* Make full use of vacation policy. No one’s going to tell you to take a vacation you gotta take care of your physical/mental health yourself.

> You are expected to manage your career and growth. Don’t rely on or expect your manager or someone else to do that for you. You’ll get lots of good advises around how to grow in your career. It essentially boils down to taking initiative and driving those to closure.

This is huge. For any junior devs, please take the time to learn about how to plan and enact career progression and technical growth. I learned the hard way that if you don't do this for yourself, nobody will.

If this was ordered by importance, I would move this to the top

> * Make full use of vacation policy. No one’s going to tell you to take a vacation you gotta take care of your physical/mental health yourself.

Always work with people smarter than you. Ethics are important. Don't stop trying to improve. There is money to be made in every IT area, follow what you like and you wont be poor or unhappy. Respect others' work no matter how crappy, specially open source/free work.

While those are all good points, I feel like

> Don't stop trying to improve.

can't ever be overstated.

Soft skills matter!

Learn how to write good emails. Write to the point of view of the person/people receiving the message. If you can't describe a requirement without technical jargon, you probably don't understand the requirement.

Learn how to phrase questions and responses in a thoughtful manner. Knee jerk responses are usually detrimental.

Learn how to present. You're going to have to make a case for your ideas in meetings. You'll also have to defend your actions sometimes, particularly with respect to operations and support.

Communication is so critical. It helps requirements become better understood. It keeps issues from becoming escalated so that you have more time to do the enjoyable part of the job: creating something for someone.

Your job is to make someone else's life better with your development skills. Whether it's saving a step in a task they need to do or providing timely information so they can make decisions important to the organization...whatever...you're there for them.

Explore what areas of development you like the most - analysis, project management, UI, backend, etc. - and follow them. Keep in mind that it may change in the course of your career.

Try to develop a good rapport with your colleagues. You spend a large portion of your waking hours with them. It's easier when you like them and vice versa.

Find enjoyment in each job. It's a long career. Don't stay with something that isn't enjoyable to you.

Take your job seriously.

I often have felt that Jr. Devs I have mentored only live up to the "Jr. Dev" role. They only do as much as they think a Jr. Dev should do and often leave work for a more Sr. Dev instead of at least trying to take a stab at something.

Example: a JR. Dev has trouble implementing some candlestick graphs. Instead of trying to work through the issues and document his thoughts in the code and ask for advice. He just leaves it untouched, for many days, then a week, before someone asks him his progress then says "while I can't quite make it happen" when really nothing has happened.

This is something I'm personally following right now - so it struck a cord with me. I see other Jr. Devs simply stick to their roles, I cannot do this - I try to understand a feature/project and work according to its requirements and not just do my work

I would hope that no Sr. Dev ever scolds or looks down on another dev for trying, regardless of skill level. I'd rather someone try than twiddle their thumbs. Good luck.

Develop good habits: physical conditioning, mental conditioning, avoiding drugs and alcohol, etc. If you want to be doing this kind of work for the long haul, protect your body and mind. In your 20s, you can be a couch potato, etc, and probably do this job. In your 50s? The proportion of people still doing this job who don't take care of themselves is much smaller.

I would add on and say: don't underestimate the physical toll of having a job based on typing at a desk. Your back, hands, wrists, arms, hips, and probably more can take a big toll directly from performing your job. If you're not careful to avoid stress, burnout, etc, then you're also directly or indirectly inviting huge risk to your heart, weight, mental health, and more.

Drink lots of water. Go to the bathroom. Have little walks or stretches in the office, at least at your desk or in your chair. Go for a walk after dinner. Do some light exercises at home if you can't walk at home. Sleep, sleep, sleep.

Start building your career so you have job security now. This means doing things to eventually move into management or doing projects/blogs/postcasts so that you stand out.

When resumes come across someones desk being a generic developer is not going to help, and it gets worse as you get older. Having something that you can show off even if its just a collection of blog posts about how you built a simple CLI tool using Nim will make you stand out.

Work on your soft skills. Being able to communicate and get your ideas across is more important then being able write the best code in any organisation. It will make you stand out. Learn public speaking and show what you have done. Be your own champion because its rare for someone to do that for you.

Lastly, learn some new technology and write posts about it. You will become the expert in it if you do this at the right time and frequently. This will open up new opportunities.

Hands off the keyboard.

There's a lot of learning to be had in taking the time to read and understand others code, in taking the time to really grok any brownfield system that you're working on, and in spending some time with the documentation.

There's a lot of work you can save yourself by taking the time to assemble a clear plan of attack before you start hacking.

(And if you're doing BDD, writing Gherkin files counts as hacking.)

There's a whole lot of rework, wasted effort, and end-user aggravation that you can save by really getting to know the business domain you're operating in.

Learn to be useful to the organisation where you're working. Don't just be about upping your own skills and stuff. Being valuable to the person who's employing you is what makes your progress in your career.

Learn to be a professional. Basic things like showing up on time, being a good communicator etc.

>Being valuable to the person who's employing you is what makes your progress in your career.

More importantly learn how to be recognized as valuable. It's better to appear valuable without actually being valuable than being valuable but not recognized, and often you don't even have a good idea what's valuable in the bigger picture on your own so accepting others valuation can help you from being stuck in your bubble.

It looks like this comment is being downvoted because it appears to endorse being deceptive.

I’d like to chime in and second the sentiment in slightly different terms: value is not inherently visible. You can waste a lot of time contributing significant invisible value to a company with no recognition or reward. On the other hand, you can provide a small amount of value and receive significant recognition just by making that value as visible as possible.

If you’re looking to have your value recognized, you need to commit energy to making it visible. This means different things in different roles and organizations, but it’s a critical skill to develop.

And it doesn’t just apply in business relationships! Learn to make your value visible; it ensures the energy you put into anything is appropriately acknowledged.

If you don't have the personality to market yourself keep yourself in a position where you contribution is obvious.

Working on a self directed project that makes tools for other developers can be fun, but if you can't sell the value of that work you should stay on a team that generates obvious features for paying customers. (which is to say work on projects where marketing will sell your work, this indirectly outsourcing making yourself visible to marketing)

All I'm saying is that most of what you're trying to accomplish relates to getting recognition and that's not guaranteed by simply doing the work - sometimes it's not even predicated on it. This is something that isn't obvious to new and idealistic juniors.

OTOH maybe that's the way it should be - first you work your ass off and get real skills then you learn how to sell but have the skill to back it up.

Also a LOT of people fall in to the trap of thinking just because they perceive something as valuable that it's actually valuable to the employer - zealous juniors learning best practices without knowing how to put them in context wasting time and effort and getting frustrated for not getting recognized even though they "are right" .

Say "yes" to new challenges, even if you think they are over your head. Everybody feels a bit of imposter syndrome, so don't let yours stop you.

There's no cure for impostor syndrome.

I have 13 years of experience, CTO and lead developer at my company and a part of me always thinks people are way overvaluing my skills.

You just learn to ignore it, but it never goes away.

Are you sure it needs to be "cured"? Lately I have been thinking that it's a blessing in disguise; a painful -but effective- motivator to improve and seek out new skills and more knowledge.

Yes, it comes with a side of depression, and that really sucks, but I've found if I'm deep in some tech I don't know, it doesn't seem to affect me nearly as much.

Could it be jut us getting restless? The feeling we haven't learned anything new or faced any new challenges lately?

> Are you sure it needs to be "cured"?

Nah, as you say it is a blessing. And I wouldn't trust anyone who thinks they're underrated or they know "enough" about anything.

> Could it be jut us getting restless? The feeling we haven't learned anything new or faced any new challenges lately?

I bet one could win a Nobel prize for breakthrough research and still feel like a fraud. "Ugh, did those idiots really give _me_ a Nobel prize for this? What were they thinking?" :)

I'm confused. Are you saying the CTO and lead developer overvalue your skills or that they too think others overvalue your skills (as in they don't think as highly of your skills)?

I think he is saying that he is both the CTO and the lead developer

That's correct, thanks!

Ah! Thanks!

Don't self-destruct. This may seem obvious, but surprisingly many people get this wrong. There will be moments where you have incomplete data on some situation, yet feel strongly about it, and have a strong urge to do some symbolical career-limiting step as a reaction -- for example, threatening to quit over some minor technical decision made by someone more senior that even turns out to be correct a few years down the line, or leaving a product that's on an exponential growth curve because you don't like to see the team changing as it grows (this is valid concern, but there's also significant upside to being an early member of a successful product). If you're in a situation like this, it's usually a good idea to wait a month or two before doing anything; usually the urge is over by then.

Related - hang in there (sometimes).

When things get their craziest, when entire teams are getting fired, that's sometimes when career opportunities open up and massive advancement can happen.

Find a mentor. I was lucky enough to have a couple more experienced developers take me under their wing when I was new. I learned so much from them. This idea of mentorship has fallen out of favour, but I now understand "there is nothing new under the sun".

Pretty much this. Get hold of your ego and be humble enough to take lessons from experienced people who have track record of delivering successful projects. It is imperative to get the basics right before being able to take on more responsibility later.

    "We don't rise to the level of our expectations, we fall to the level of our training."
Make sure you get as much training as possible before raising your expectations. It will be easier for you later when business expects senior output from you but you are under constant pressure on both personal and professional fields.

This. if u wanna become useful faster. Which will propel all else further.

"Languages are tools" too, thats my motto. Most things around are tools (house, insurance...) just people do not want to see it.

Find/invent a project of your own only, something thats seems doable and u would really use/need it, and try do it. Will teach u wonders.. about life as programmer.. which is not same as everybody else. Much more philosophy and multiminded-ness is involved.

As of how to find a mentor.. i do mentor people, and it seems a cross between a matter of luck, AND mutual "liking each other". You may have to ditch your ego, and the "i know it all"-ism for quite a while.. and believe me, its more useful to be scolded by someone in the know than to be awed by someone who does not.

good luck

How does one actually do this? I have a hard enough time finding close friends of any kind. And mentorship is a pretty big thing to ask of someone.

You don't. One thing I've noticed is that mentorship is one of those things people like to toss about as well-meaning advice, but it's an empty suggestion more than anything else. Realistically, what you can do is make an effort to join some kind of programming e-community that's more intimate than HackerNews and integrate with that community over some time, and then ask them for advice. You can find a language-specific Discord/Slack/Gitter/IRC channel, integrate (lurk, then post, become a known quantity), then ask more specific career-oriented questions.


In my first two roles I found that more senior level developers gravitated towards mentoring me anyway. I didn't really even have to seek it out, usually just getting in the door and humbly admitting to yourself that you don't know as much as you thought you did is enough for people to want to share their knowledge with you.

Don't be afraid to ask questions in the workplace when you're new, that's the only cardinal mistake you can make, the mentorship will come automatically.

Luck is a major factor.

Some things that might help:

- ask lots of questions, listen, and take notes - be humble and gracious when you receive feedback. Most people avoid mentorship because its really hard to deliver negative feedback delicately. Easy to avoid it altogether. Ask for feedback actively, and start with: "what can I do better here?" or even better, before starting "how would YOU attack this problem?" - scout the organizations you want to work for ahead of time. Creep linkedin profiles, etc. Do you have similar interests to the senior devs (which will allow you to connect on personal level)?

Some companies have internal mentoring schemes - perhaps more likely the larger the company.

Professional institutions typically do too.

Either option takes the burden off asking someone, since you're merely applying to a pool of people that have declared a priori their willingness to be a mentor!

Cannot upvote this enough. IMO every thing else is secondary to finding the right mentor.

Applies esp. early, but also later, in ones career.

Beyond software development, focus on building relationships with the people you work with at your company and in your industry. This will pay dividends throughout your entire career.

Do not try to understand everything in order to do something.

Yes, understand principles, but don't get frustrated because you don't understand everything from the silicon up to the photons coming out of the screen. You'll never understand it all. Try to understand more, but don't try to understand it all. No one understands it all.

I've seen this paralysis stop so many junior developers in their tracks. They beat themselves up trying to get it all before doing anything.

I'm gonna be real; I have only the vaguest idea how the VM works in Ruby, along with it's garbage collection (also, they keep changing it for the better). Yet, I've been programming in it for almost 10 years on a daily basis. I don't need to know this in order to setup some validations in Rails. Sure, it's useful when you hit some problems, but not critical for most work.

Unless you are in academia/research, your job is not to produce software - it is to solve customer problems, add customer value, and help your team-mates and wider colleagues. You should be able to trust your colleagues on the marketing and product side of things, and while you should be honest with them about tech limitations/requirements, you need to be able to work with them to deliver product.

But to have a career you also need to pad your resume with the right buzzwords. Just solving business problems without considering your resume is good for the business but will make it very difficult to advance your career if you are an engineer.

Most valuable skill that wasn't yet told: learn to help yourself. You won't always have a mentor, or formal education on a subject. The ability to succeed despite external support is basic.

Don't fall in love with a random company, expecting reciprocation; wait for the company to show love to you. If you do an astonishing good work and the company doesn't reward you, pull back, do "normal" work, then look for another company. Most companies either show their appreciation quickly and regularly, or never.

Don't chase money, only focus on doing hard things that scare you at first (think: at the limit of what you're capable of), then change when you're done learning. Iterate for > 10 years.

Start off by going deep, not wide. You'll pick up other languages and technologies over time. Pick a stack that appeals to you and focus on it for a while, learning its idioms and best practices and improving your development fundamentals.

Good advice, mine is somewhat opposite :)

Never, ever, stop learning. Don't feel too bad if you can't find time for a personal project like everybody else seems to have. Just make sure you are up-to-date with the hectic changes in the programming world.

Every single time you're on HN and you're reading an article about Kubernetes while you're just a frontend web developer expands your horizons and advances your career.

And when you know something about most things, with some specialisation, go freelance and expand your skillset and knowledge further.

The moment you stop learning is the moment your career crystallises and dies.

Don't overestimate reading an article about Kubernetes. It creates awareness of the concept and what it could offer, but that is not the same as going wide, it is too superficial.

Reading is good, but often gives us a illusory perception of understanding, but things tend to stick even better when you experiment with them.

Agreed. Do something really deeply and for a long time. Getting started with a tech is always easy but only through several release cycles you learn the real difficulties of programming which are making changes to an old codebase, when to refactor, training new people on the system, deciding on adding new tech. But then don't get attached to this but be willing to move to other things if they make better sense.

In summary try to develop good judgement based on real world experience.

I agree to this, but in the sense that you should dig deep and understand how something works under the hood.

For example, ElasticSearch is “fast”, but what makes it so? What trade offs were made to make it “fast”?

You may start seeing patterns on how good/bad tech stack are built (aka the meta), and those meta would help you a lot down the road in knowing what type of toolset you can use, common type of problems a given architecture would exposed to.

Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact