Ask questions, no matter how stupid they may be. REALLY. Ask any doubts and questions you may have regarding coding practices, implementation details, technical workarounds, etc...

Even if the questions sound silly, which is what terrifies the most, just ask. At my first job, I was too afraid of asking my teammates unless I came up with some smart-sounding question.

Fast-forward a couple of years until now: I have a teammate who is quite less experienced, and revealed me he does not want to ask questions because he thinks it's a waste of time for the other person and/or he feels silly to the whole team.

I attempt to mentor him and teach him to ask questions, no matter how dumb may be. We've always been there.

This leads me to another aspect: have empathy towards your colleagues.

Always understand what you are doing, never accept advice like 'do it exactly like this to be on the right side', in short: stay clear of vodoo. Learn scripting to avoid repeating yourself, learn templates/macros or whatever it takes to avoid code duplication (it takes an effort, but is really worth it). Have some kind of document where you can write down your experience, what was learned, what kind of problems you have solved - patterns keep repeating and writing stuff down helps to be aware of these patterns. Try to learn reading code - it's a skill of great value. Learn specifics of build tools as a lot of time gets wasted if the tools are not understood

Be a bit sceptical of people who pass out judgement and advise

Focus on a niche and specialize more than “software”. As a junior you have some time to figure it out (but don’t take too long). Software is everything these days, so if you can focus on a subfield you’ll maximize your future earning potential and lifestyle. It’ll also help you stay technical well into your career.

To do this, keep your eyes open for opportunities to go deep into something interesting at your job and be the company expert on that topic. This is a nugget of a personal brand. Then take this and expand on it outside your first job. Blog about it. Speak about it. Create open source about it. Find the next job that hires you for these specialized skills. Rinse repeat...

Worst case is you can still switch, or go back to just “software developer”

Keep good notes in a form where you will remember you have them and look at them.

Which is a fluffy way of saying when you tell someone at 4:55pm "I'm leaving now but I'll get to it first thing in the morning", you actually do it first thing in the morning.

Write as little code as possible. But make sure that whatever code you do write is readable.

Try not to sound so surprised when your code works!

Don't ask a colleague every time you don't know how to do something. Investigate, learn how to debug. Building intuition is what's going to take you to the next level. Also, try to not get stuck with same tools for too long.

Start with the support backlog.

There is no better source of knowledge than solving software issues. You see it all in that backlog. Deployment issue, build issues, bug fixes, feature changes, merging problems, log files, web server configurations, DNS issues, certificate installations, database errors, database updates, connection issues, you name it. It is in there.

Once you feel comfortable with that backlog, look at the source code of your application and you will then ask your self, WHY IN THE WORLD WAS THIs BUILT THIS WAY?!?! you will find everything wrong with the application and that is a good feeling.

Start with Supporting an application before developing it.

Lots of good advice here already, I'll add two things:

1: Never trust a recruitment agent.

2: Don't be afraid to ask questions. I've had 30+ contracts in 18 years, and I've lost count of the number of times I've been in a big meeting where some manager or director is specifying something which makes no sense, and all the other developers are just nodding quietly. It saves a LOT of time if someone politely says "sorry, maybe I'm being a bit dumb, but I don't understand" right there and then. 4 times out of 5 it turns out that nobody understands, including the guy talking about it.

Know your tools. Be a good teammate - this is a team sport. If you're going to do something more than once, automate it. Get paid for the lines of code you don't write, rather than the ones you do.

When trying to learn how to implement something, or fix an issue you have, and you end up in the documentation: Read the documentation page for the thing you found. All of it.

I know there is a lot of stuff you do not know, and it can be truly overwhelming to try to stop, and read for 20 minutes when your parsing might get you the answer you want in 1. But you will learn a lot more, and you will start running into issues less and less frequently.

In the long run, it will genuinely save you time, and you will understand the tools you are working with much more deeply.

Start learning how to figure out what your customers want. At the end of the day, it doesn't matter how pretty or scalable your code is if it doesn't solve real problems. I'm not saying that you shouldn't learn how to be a great developer, but a lot of great developers end up working for a series of companies that build cool technology but don't do well.

Ask whether you can sit in on calls with customers, either prospective or current. You will find out what they want, and whether your product is solving their problems.

Read books on programming and design. In today's world of stack-overflow-driven-programming, just reading docs and non-clickbait blog posts make you stand out by having more than superficial knowledge of things, but having dedicated focused knowledge expansion through reading books that aren't immediately goal-directed can accrue superpowers. It's exceedingly rare to encounter a developer who exhibits the kind of breadth of knowledge that comes from prioritizing focused reading time.

Learning how to write decent software just takes time and comes with a lot of failures in between. Good peers know that and you should too. But they will often leave you with some easy stuff to get you productive and it is very easy just bury yourself in this work. Try to observe what your seasoned peers a doing, listen to conversations between them, ask questions if possible. Things that happen away from keyboard is nothing someone teaches you in school, but there is a lot to learn from that.

Try and understand the big picture, not just the tiny corner you've been assigned. Working in an iso-chamber is neither pleasant nor productive. Understand where you fit.

Don't just accept the API you're given and throw your hands up when it doesn't work. As far as is practical, understand how things work all up and down the stack.

Writing some React code and it doesn't work for Chrome on Linux?

You should in principle be prepared to debug not just your own code, but React's internals, the Chrome JS engine, and the Linux kernel itself until the problem is identified.

Obviously that sort of thing is a last result, but you should in principle be prepared to do it.

Remember that working for someone else means that other person, who has th means to take the risk has mad a calcualtion that there is more income generated from your work product than the money spent on obtaining it. So work exactly as much is reasonable and use the rest of your time and energy to take the same gamble on yourself, out your extra effort into yourself & your own bussiness India’s rather than someone else’s ( for negliagable reward)

Keep a daily log of the things you learn, decisions you make, and ultimately, code you write.

It will be golden six months down the line when you're questioning your career.

Read other people's code.

A bit of self promotion, but I was interviewed a few years back on how to become a software architect, I think its solid advice to any developer: https://www.roberthalf.com/blog/salaries-and-skills/how-to-b...

I'm still a junior dev, but the difference between my successful and unsuccessful peers are their tenacity and curiosity. Don't be afraid to ask questions, put in the work to try the debugging yourself, stick with the problems you encounter. But ask tones of questions, as there are often more experienced devs who'd love to help!

Programming is like articulating/verbalizing a thought. Increased verbal fluidity = faster programming. Nootropics.

I've already written down everything I know in https://www.quora.com/What-are-the-best-secrets-of-great-pro.... I keep updating that answer from time to time.

The company where I am employed the ideology is time an employee spends in cube + salary paid + company resources used must produce maximum profits. So the time a prospective employee takes to ascertain a problem and implement a fix is far more valuable then the amount of times he/ she takes to solve the problem.

Read the clean code book by Rob Martin and the head first design patterns book. Both are musts for software engineers and Amazon top sellers for developers. Other than that be like a sponge and learn transferable skills in one or two mainstream languages, you can't go wrong with Java, c#, sql and angular.

read more code than you write. for your entire career.

Be nice. Work hard.

Don't smoke

Talk to people.

Learn to learn.

Take ownership

Keep learning

Don't be afraid to ask for help. But don't ask for help until you've made an honest ever to figure it out yourself. You learn best when someone isn't spoon-feeding you the answers.

Your project will be cancelled and your team will be reorganized. The manager you love to work for will leave.

The most important part of writing software is being able to understand it. You should be able to understand it when you're writing it, debugging it, and six months after you haven't touched it. Other people should be able to understand it. That principal informs the following rules:

1. Code for simplicity first. Do the simplest thing that can possibly work. For whatever reason in this industry, people are seduced by cleverness and complexity. You're doing a job, not trying to prove how smart you are. Clever code that is hard to understand isn't smart. The problem you're working on is probably simple. Don't try to make it fun and sexy when it isn't. Don't make something harder than it is because it would be cool to use the new shiny ____ to write it.

2. Don't repeat yourself. This is the opposite of simplicity, and your problems compound the more you do it.

3. If you have code that you are afraid to change for fear of breaking it, you've failed to make it simple and understandable. All the testing in the world won't help you if you don't understand the black box, and need to change the black box.

4. Code for readability. If you can't look at a line of code or an error message and understand what's going on, you've failed to make it simple and understandable enough. Functional code helps here; if you have to navigate between 50 different files to understand what a function is doing, something is wrong.

5. YAGNI. You will never, ever, ever need the thing you're about to spend time on and that dramatically increases the code complexity. If you ever do, it's much easier to refactor something simple than it is to work around something complex that made the wrong assumptions. Build systems in small steps.

6. Use the compiler and type system. Everything should be as strongly typed as possible to prevent future you from messing things up. The compiler is your best friend; make it work for you and write code so that when you inevitably have to change it, the type system prevents you from making a mistake.

7. Get good at debugging. This is a skill that you develop that nobody teaches you for whatever reason. When you're writing code while thinking about how it will be easily debuggable later, you're doing it right.

8. Use spaces instead of tabs. You'll make more money. Also turn on visible whitespace in whatever editor you're using and delete those silly extra spaces on the end of lines. I can see those and they're the code equivalent of walking out of the restroom with toilet paper on your shoe.

Kind of a hodgepodge:

Rack up experience. It's much better to be working than not working. It is much better to have 2 years of experience and learning vs. 6-9 months looking for something perfect -- this is especially the case for juniors. Just take the first job you can get. Also, don't underestimate how much the rate of learning differs between various workplaces.

Try to work somewhere that invests in people, especially juniors. Startups will be "more fun", and you'll likely to get to work you're not really "qualified" to do, but you won't learn how to do it well. One of my biggest regrets is not finding effective mentors earlier in my career. Sometimes a more "boring" workplace is better for this.

Most employers will judge your skills by the brands on your resume. This mostly happens because there's no other reliable way of determining how good someone is when hiring them, short of "I have personally worked with this person before and can vouch for them" (the gold standard). A mediocre developer who managed to clear Google's bar may be less of a good hire than someone who worked diligently at a consulting company -- probably not in the average case, but it's possible. Note this contradicts a lot with the last piece of advice. It's a puzzle -- brand vs. skills.

Focus on your social network. Most good jobs, especially in more senior roles, will be obtained through prior coworkers, investors, or other people you know/have worked with. Keep up with people. Try not to piss people off. You'd be surprised how useful it can be to leave a trail of goodwill behind you.

Understand that it is management's job to advance the shareholder's interests. Most of the time this means they'll try to do what's right for employees. But it also means that when the situation demands it, they will lie, withhold information, fire people, report things to HR, and try to pay you as little as possible -- that is their job. Filter every announcement and communication through the lens of "how does this advance shareholder interests"? It's not fair to say "everything management says is bullshit", but it's directionally correct. Truth is not the priority.

Focus on developing skills that won't become obsolete. This means prioritizing domain knowledge, CS fundamentals, etc. over the details of one language, company, or programming environment. Try not to specialize in writing software per se -- the market rate for this is rapidly heading to zero with outsourcing and remote work. My friends who have the best careers (happiest, best-paid) are people with very deep expertise (PhD + 10 years experience) in areas like semiconductors, networking, or a particular business domain (e.g. hospitality/travel, high-frequency trading) . The trick is not to specialize too early -- wait to find something you really love.

Most startups aren't worth it. Some are. Many people have a binary view of this: "startups good"/"startups bad". It depends on the people, the market, and a lot of other factors. There are a relatively small number of investors and founders who can reliably beat the averages. But not many. Informational advantages in this area are worth a lot.

Silicon Valley is basically Hollywood. People move around a lot. Packs of people who work together cross-recruit into new companies all the time. Try to get into one of these "tribes". It will help you immensely for your entire career. The PayPal mafia is a great example of what I'm talking about.

As you get more senior, do your homework and really stress out about which job to take. It's worth it. This might be counter to what a lot of others say but IT MATTERS. It's the difference between working your ass off for four years and getting nothing, vs being able to afford a modest retirement after 4-6 years.

Plan to work 3-6 years in places, if not longer. It demonstrates commitment and people in the upper echelons of business (investors, CEOs, high-level management) respects that a lot.

If you work at a startup, don't always optimize for the biggest stock grant. 0.5% of a company that fails is worse than 0.25% of a huge success. Understand that bad companies fail and good ones sell for tens of billions. Our intuition wasn't built to handle 10 orders of magnitude differences in outcome.

I blog about a lot of this. http://davidralbrecht.com/

Exercise

learn to touch type

Learn how to "dig in." At least in the enterprise space, problem solving is more important than the code you write. I have seen many people come and go because although they can write Java, they can't figure out what to write.

Practice ..practice.. practice.

My advice would be; don't do it, unless it's a way of life.

Being a software developer is easy, I've seen loads of them, these are the people who's work I end up fixing, it stresses me out and it costs the company more because they've paid two people to do the job.

Being a good software developer is a way of life; if you're going home after work and looking at ways to improve your life or other peoples lives by writing software, you're doing it right.

Work with the best people you can find, the more experience these people have than you, the better. Learn what you can, and make it your aim to be the best, one day they'll come and ask you for help. This is the point where you thank them.

Find something you're good at, find a niche language in your company or tool set and become the go-to developer for it. As soon as you attain that, and you're known as the go-to, find something else, work on the new thing, and maintain the old, find languages you enjoy and master them.

Eventually, you get to a point where you're asked to fix/write code in a language you've never used, and yet, with the API docs at hand, you don't even skip a beat.

Also, remember this, no matter what you think, not everyone is far better than you at this. There are some exceptional developers, but most are either putting in a lot of hard work for the results you see, or they're average.

Finally; Never release on a Friday, and never make changes to production.

1) If you're not a native English speaker, always improve your English. 2) Start your open source side project and work on it in your spare time. 3) Improve your skills by reading books and attending online courses. 4) Change your job/project every year.

It's not about you.

When seeking a job: It's not about you. It's also not about the company you're working for.

When improving the ugly code in the job you just started: It's not about you. Don't argue about silly things like brace styles.

As Pink Floyd said, "all you touch and all you see is all your life will ever be".

The more fond you are of your tools, the less likely you may be to try others. Don't develop preferences too quickly. Try not to emotionally invest yourself in decisions you've made about languages, libraries, editors, operating systems, and other technologies that you will spend thousands of hours with. Technology changes so quickly that you can easily find yourself mastering a local Maxima where others have already left and moved onto higher ground. Try new technologies and adapt with the times.

1) Try to learn as quickly as possible which parts of the code are critical infrastructure and which parts of the code don't warrant perfection. I know this is probably difficult in an environment where every single character in a PR is heavily scrutinized, but time is a finite resource, and you need to be very careful not to overengineer things are not critical or will be replaced eventually. This was one of the hardest things for me to learn. Perfection is the enemy of the good.

2) Learn to love working on legacy codebases. This will happen everywhere you work. You will rarely (if ever) have the opportunity to start from scratch. If someone asks you to use an existing piece of code, and you decide to re-write it because you don't want to take the time to understand what's going on, you will A) appear to be anti-collaborative and B) reinvent the wheel, thereby wasting time. Obviously, there are scenarios where re-writing something from the ground up is necessary, but make sure all stakeholders involved agree and that you can estimate it correctly.

3) Always try to coax out as many details from designers and product managers/owners wherever possible. Perfect requirements will never exist but you want to be equipped with as many use-cases as you can before you start hacking on something. This may sound a bit waterfall-ish, but PMs and designers are not omniscient creatures. There is almost always some sort of gap that you may be able to help identify.

4) Don't be a dick, because there will almost always be someone who knows more than you. This applies to comments in PRs! Even if the entire company treats you like a god, that does not give you the freedom to treat others like worshippers.

5) If you are asked to estimate how long X will take, DO NOT give an answer until you have enough details so that you can make a reasonable estimate. If they force you to give one, pad it 2x or more depending on how much you don't know about what needs to happen for the task to be marked 'done'. Even better, ask them for a separate fact-finding task (spike, POC, or whatever you want to call it) so that this can be more easily tracked.

I could go on forever but these are some of the more non-obvious things I don't hear talked about enough.

Be happy about working on things that are feel way to hard - it means you're learning fast.

Write code for fun. Find a hobby away from computer for sanity.

Consider the risk of burnout - even with great mentor and challenging work a toxic environment is not worth it long term.

Care about ergonomy of your workspace now - adjusting height of monitor costs you nothing, good keyboard and wrist rest cost less than you make before lunch. Carpal tunnel, ulnar neuropathy and back problems will start hitting you and your friends when you are teaching peak of your career and are no fun in general.

At some point, you will be confronted with a problem (a bug most likely), and you think it is beyond your ability to fix. Do not give up. If you can't figure out what's wrong, figure out what isn't wrong, and keep figuring out what isn't wrong. This may not feel like progress, but it is. Do not go to your dev lead and say "this one is beyond me". Say "I'm stuck, but I've tried X, Y and Z, and it's none of those things. Do you have any ideas?"

Biggest issue I find with developers right out of school, is that they often feel ok throwing a problem over the wall to a more senior dev. The truth is, all of us are confronted with problems we don't know how to solve. That is the job, but if we don't solve them, who will? You will not magically discover an ability to solve impossible problems and diagnose inscrutable bugs. But if you don't give up, and you fight your way through these problems again and again, you will develop confidence, and the instincts that allow you to do it a bit quicker next time.

On a related note, do NOT rejoice when a bug you've been struggling with suddenly goes away (another thing I've seen many times). Nasty bugs "going away" is one of the worst things that can happen. I promise you, 90% of the time it's coming back. And it's coming back at the worst possible moment, and possibly in a less friendly form.

Ask questions. Ask them all the time. Never refrain from asking a question because you feel you should know the answer.

The mistake I see all the time is juniors nodding because they fear letting me know they don't understand is a weakness. A sign they do not master the language (in fact I see this with most people). Always ask questions. It has multiple advantages: (1) it answers your question so you can understand, (2) it shows me you want to understand the topic under discussion, (3) it helps me explain the topic by guiding me to the parts you find complex, (4) the nature of your questions shows me how much you understand of the topic

Being able to stop someone and ask what a particular term or concept means is a super important skill for any engineer. It does not list you as a fraud, it lists you as a great learner. Remember that. Always.

Now, when asking questions ask the right questions. There is enough material here for me to provide just two links and let you google for the rest. [0][1]

P.s. Bonus reason: Assumptions are the mother of all f*ckups. Ask to verify things you think you know!

[0] https://jvns.ca/blog/good-questions/ [1] https://hbr.org/2018/05/the-surprising-power-of-questions

Don't agree to work for peanuts. Young developers are easy target for "startup" or predatory corporations as they can do mindless coding for hours and if you throw in free pizza on Fridays, they'll work day and night for almost nothing. Once you get burnt out you get replaced with another young wannabe developer. But you'll have damaged health and no savings. If offer is low and you think you'll get experience - you won't. Just look more for something that respects you.

If you can, don't hesitate to ask senior dev for help (but only once you've done your own research). In that case, knowing how to explain what's the problem, in the context of what you are trying to do (the context is important because of the XY problem). Communication with non-dev and person outside your project is important, usually those person will either control the budget or be users and stakeholder. Admit your mistakes, especially when they affect other persons.

Learn the tools that you'll use to develop software. Becoming proficient in the tooling will help you greatly with the actual development.

Some things you can do for example:

- Using linux? Learn to use the CLI

- Learn to use git/svn/... (whichever you use at work)

- Get comfortable with your IDE (shortcuts, customize to your liking, ...)

- Learn to use a profiler (JProfile, ..)

Those are some pretty general things but they'll help you in any job where you write code.

The tools are (imo) just as important as knowing the language you use.

- Be able to delete all your code without feeling sad about it. It's freeing to be able to delete code if a better solution presents itself. Generally these things can be found out by talking to business people and other developers, by having a session where you draw the proposed solution out on a piece of paper or by just iterating through it yourself.

- Confidence comes from trying, and failing, and trying again.

- Burnout is real. Know when you are close to it by knowing what triggers your anxiety and stop. Having the ability to remove yourself from a stressful situation, even if just for an hour makes all the difference .

- Test your steps. If you can write code to test your steps then it's great but most of the time a simple browser reload/button click or command line run action with verify if your change works will be good enough.

- It's fine if you don't know. Having the ability to ask for help will mostly be met with respect.

- You are not defined by your code as a person :)

- Theoretical pureness mostly gets in the way of solving an actual problem because of the endless debate it sparks in a team. If your goal is to write code that is readable for someone in the future then it doesn't matter what design pattern you use. Computers are fantastic at understanding code. Humans however need some help.

- Try and clean up as you go. Like your home, if the dishes pile up too much it becomes unliveable.

- Lastly, learn how to understand legacy code. It's a fantastic snapshot into the way the business was thinking at the time and to see it evolve and be that change is a privilege to be part off.

Good managers are rare.

Don't trust your manager(s) that they are going to lead/manage/mentor you in a way that will really help you. They are not.

If I allowed myself to be really cynical, they are mostly out for themselves. Most will have no problem using you or even throwing you under the bus to get themselves ahead (or protect their own jobs). And this involves things like having you do things (aka work with less valuable techs) that they don't want to waste their time with. That is what `delegation` is.

But don't worry though. Most of the time, they have little time left to think about ways to take advantage of you. They are just busy managing their own jobs, your fellow team mates, and their own bosses. Oh, and figuring out how to beat fellow managers. They have their own family/retirement-plan to take care of. They don't have much time left to manage you after sharing extended pleasantries with their own bosses.

And the more successful your manager seems, the more guarded you should be about them using you to their advantage. I've been around and of the bosses I had over me, two are now in high level position (VP) at really well known brand name companies in US. Because we were in smallish startup shop with cubes/offices near, I was able to observe them from nearby. Both were really good at pleasing higher ups (not necessarily through excellent work but with friendship), have no problem with pushing around those under them, and just do good enough job of actually managing the team.

Also, don't settle. Don't settle into a role that you feel comfortable. If you feel comfortable at a role, it's time to move on. And time flies. Make most of it.

Don't set yourself on fire to keep your company warm.

A bit late to this thread, and this is coming from someone who used to code, but does not anymore, atleast not actively.

Avoid what is known as 'Somebody Else's Problem Field' behavior. (Here is the link: https://en.wikipedia.org/wiki/Somebody_else%27s_problem)

What I mean to say is, a lot of times developers have an attitude which says "I'm done with my work, now if its not working, it's somebody else's task" or variants of that dialogue. As a developer, I understand and concur with your position that you might have done all the things right, but as a team, you are not helping matters by saying that. Volunteer to check your code, do more, and try to figure out where the problem is, like what input you are getting, what is the output, where is the code failing. the more you help in these cases, the faster the things get done.

This is also a common behavior, when someone asks you for a data or a piece of code, and you send her a straight forward export/import in the raw format. Occasionally, that might need the other person to do a lot of clean up and other operations, (with a bit less context), and would have been easy for you to do in the first place. As a developer I did that a lot. On the receiving end, this is one of the most frustrating things, since I need to account for it in my tasks beforehand. (Example would be a simple dataset, given to me at SKU level - cos requires a straightforward query - while if extracted aggregated, would have taken 5-10 more minutes for the developer, but now the asker is expected to spend sometime cleaning up and aggregating that data set. Might not always be this, but I hope you get the point.).

my 2 cents.

Learn how to understand who the "customer" of your software is and how to deliver what they need. Learn what you're inherently good at and not so good at (and develop strategies to work around your weak points.) Learn that code reviews are discussion of how you did something, not an attack on your ego. (or at least they shouldn't be.) Find mentors you can trust.

Some great advice in this thread already. I'd add learning to use git from the command line (together with the concepts of a rebase, a merge etc), it will be useful in every single CS job.

Figure out what parts of the stack you're more passionate about. This may shift over time, but if your working on things that you truly think is interesting it will keep work from being work.

Spend time with the code before you ask for help. Try different things, break things locally and understand how the code stands in a bigger system level picture. If you are in a good organization, they will support you breaking things in staging as it will provide them a better picture of code reviews etc. So break things and learn fast.

Most importantly, junior software engineers and interns often complain that the work they do is not impactful - it may seem that those around you are doing impactful work (and it might actually be true in a very few cases), but don't let this effect your peace of mind and not let you give your best. Every work you do must show a characteristic of your quality. Engineers must be able to provide anything in their field, at all levels of their stack, regardless of how important they feel their work might be. Always respect your work and be grateful for getting an opportunity for working on it because someone did not get that chance.

A senior developer told me early on that all software is compromise. Thinking back to that has often saved me when I realize that I'm trying to find a perfect solution. There is no perfect solution. Also, read books, especially The Pragmatic Programmer. I finally read it this year as a Sr. Developer and there were some great nuggets of wisdom.

Find a hobby. Interesting things happen at the intersection of technology with other things, so find other interests apart from software. Technology skills, management skills - these are table stakes. Perhaps even more if you take the generalist career path, having some additional domain knowledge or value-add that you can bring will be important.

It's tempting to feel like asking numerous questions can be "bugging people". Unless they tell you "Sorry, I'm busy today from X to Y" (they should if they respect their own time), look at it as providing the opportunity to teach

It sounds silly at first but for those of us who like to share what we learn, or think others aren't interested, we love it when anyone has questions for us!

Don't be afraid of failing a lot either. Personally I've learnt a great deal of things just because I tried to do nonsense things that failed and taught me a lesson.

I first dove into unicode (and did a talk at a meetup) because I had this absurdly stupid idea to make a program that "prints hotdog emojis every X minutes". It didn't work but just asking "Why?" lead me to a lot of answers and even more questions.

You never know when seemingly useless info comes in handy again (like obscure modules in the docs for your favourite language)

Learn why things work, not just how to make something work.

You'll probably have plenty of times where you know that "if I write this line of code, this thing happens, and that solves the problem". Dig into exactly what that is doing and understand why it works as it does. A lot of the time this just means reading all the documentation (not just the 1-liner you can copy/paste and move along) and source code of libraries.

A good exercise you can do is to open up some code (ask a coworker for a good place to start), look at it line-by-line, and ask yourself if you know exactly what is happening on each line. You probably won't know and that's your trigger to go read up on something. From there you'll have great questions that a coworker should be happy to talk about with you.

In my experience, new developers that take this approach of truly learning (rather than just making things work) grow fast and impress the team.

As you start to gain some experience it can be tempting to think your particular philosophy, framework, solution to a particular problem is the right one. Over time, you'll find lots of you assumptions and beliefs that you thought were beyond doubt change. Keep an open mind and don't assume you're right.

Don't say no to work just because it is not using the stack/vertical that you want to be in. Rejecting offers and jobs just because it is not in your preferred tech stack/department/vertical is the worst thing you can do for your career. I learnt this the hard way. Make sure you don't.

Never stop learning technical things. Also, learn to negotiate, learn how to be organized, learn to prioritize. Both deadlines and requirements are very very often negotiable and movable. Even if deadline is not negotiable, the requirements typically have room in interpretation. Being dependable matters a lot.

If you never say "that estimate is too small" then you cant blame manager for assuming the estimate is good. Saying no is an option, learn to do it politely.

Sometimes manager is pressuring you, sometimes he/she really just asked when it is going to be done. Don't panic, answer truthfully.

You cant make up tomorrow or next week for time unexpected spent on something else or just wasted. That is not how it works. Factor that into estimates (whether formal or informal).

Socialize with people in your organization. Get to know people outside your team, especially those from non-technical departments. Try to have lunch with different groups in different days

Why:

1. Chances are you'll meet very interesting people, with a background different than yours. This is invaluable, in my opinion

2. You'll understand how the organization works and how information dissipates.

3. You can learn about their jobs, and if possible, find ways to make their jobs easier for them. Do someone a favor, they'll most likely return it.

3. Networking can provide very interesting opportunities in the future

4. You'll get perspective from outside the technology bubble

Physical exercise. If possible, try to do it at least 2 days a week. Besides the obvious physical health aspects, regular exercise is a performance boost for intelectual work.

Best of luck!

At the company I am employed with the ideology is the time an employee spends in cube + salary earned + company resources must = maximum profits. So this means the amount of time a prospective employee takes to ascertain a solution is way more valuable then the times he/she takes to fix the problem.

Be nice to people. Accept other people point of view, but don't be a pushover as well, try to form your own ideas and ways of coding. Be proactive - if you don't have nothing to do, look at existing codebase and try to derive why it is the way it is and what can be done to make it better.

Explore everything early. Get rid of your preconceived notions of things and just experience. Turn your judgement of things and others down a couple notches so that you can gain more experiences. Work to understand systems and people, there is so much to be gained from learning from others.

Some foundational stuff I usually recommend: - algorithms and datastructures (princeton coursera course) - functional programming will make you a better developer - "head first design patterns" is a book that will get you to understand the heuristic of design patterns in OO fast

Where I'm employed the company's philosophy is employee time + salary earned must = overall maximum productive results. When a prospective coders interviewed the time spend debugging and recompiling takes precedence over how many times he/she attempted to fix the issue.

I would share the following principles to apply to your career (from my martial arts studies):

Be Honest.

Be Humble.

Respect self and others.

Practice diligently.

Seek perfection of character.

And would also share the following quote from Hiroshi Saito (CEO of Chateraise) which I came across later in life and thought it helps to change your perspective:

Everything outside of me has something to teach me.

Robots are coming and so is automation. Programming opportunity will only exist in custom projects but most companies want to use COTS solutions to not beholden to contractors in the long run.

This change is starting to emerge and the programming opportunities for the future will start to erode.

If you use a compiler do not ignor ever ever the warning messages. Aim, from day 1 to have a compilation warning free. Write code to be read by humans, and do not ignore writing testing code, more or less you should have twice code in testing than real code under test.

Grind on leetcode until you can do any problem quickly. It's all that matters for interviewing and you'll get a job making more than people with 15 years of experience that can't leetcode but can create beautifully architected apps and systems.

Find a project you are passionate about that you can pursue on the side.

It can be both your portfolio and motivate you to keep pushing the envelop.

I do these short little exercises in programming to explore different concepts. Usually make a rough POC for an idea or some kind of interface.

If useful, I asked a similar question a while back — with some great responses:

Ask HN: Senior developers, what would you tell a younger you?

https://news.ycombinator.com/item?id=13168798

Read as much as you can stand.

Draw lots of doodle-diagrams, then throw them away. Draw again.

Watch YouTube videos. Some people learn better by watching.

Above all, code a lot. If it doesn't make you happy, quit. If it does make you happy, look for more ways to improve your personal learning style.

try to be autosufficient. if you have a problem, try to fix it yourself. try googling, reading source codes if you have to. it's very annoying when people come to me with questions that could have been resolved by doing 5 minutes of research online.

Document everything someone teaches you. Having to be told twice is not ideal for a jr. dev.

The philosophy of the company I work for is: make sure the hours spent in cube by employee + salary earned = maximum results. So on interview a prospective coders debugging time is way more important the times he/she fixed and recompiled.

Write everything down. Even better commit the things you write down. Take notes, document best practices, scribble on your hand, whatever you can do to remember that obscure command that person executed that one time while you were half awake.

Ask questions. Don't be afraid to question something that you don't understand.

Best advice I ever got was from a creative writing class:

Writers write. To become a better writer, write more.

But then I've always treated programming as a form of communication. Maybe not literature, there's still beauty, awe, and whimsy to create and behold.

Do not over engineer solutions. Get good at communicating with the business side to find out exactly what they need.

Practice things like TDD to ensure you have a good set of tests that will allow you to maintain the software for years to come.

My best advice would be: go to meetups, choose some languages that you would like to work with and attend to as many meetups as you can. It's an amazing place to meet like minded people and learn from theirs experiences.

Stay a software developer as long as you can. Don't jump into management prematurely. You'll miss the days where you used to work on interesting technical problems rather than people problems and politicking.

from my experience:

don't listen to management team saying "this guy is the best developer I've known" - his code still might be crappy

put "solved" after the phrase you're searching in google

always have your CV ready on your computer

Read every line of code you plan to submit for inclusion into any project.

If you can, find a copy of "A Philosophy of Software Design", and read the whole thing.

It'll give you a lot of higher level things to think about as you're diving deep into your first tech stack.

Look for two pieces of advice here that contradict each other. Find someone who knows you well and ask which one applies to you.

Become a PL polyglot ASAP. Polyglot perspective is so much wider that that of a person who only knows one programming language.

Run

In seriousness: get exercise. If you aren't in good shape it's draining, and making your life harder. Coding is hard enough

Go to a company where they not distinguish a lot about this junior or senior thing. Everybody can make a difference.

Be aware of the latest trends but trust the oldest or most documented if it's something super important.

Some developers have n years of experience, others have the same year of experience repeated n times.

The latter happens when a developer becomes too comfortable with their knowledge and stops learning, or when they emphasize development speed over learning.

If you want to be an expert, cargo cult needs to stop with you. Don't blindly imitate what others do, try to understand how things work and how they can work better.

When you experience an error you have never seen before, copy the message, paste in google.

Consistently be a great person to work with. Be a team player. Give feedback with kindness.

Cultivate another passion of you. Software development is just a job and should remain so.

Dont be a junior software developer... You'll never get the responsibility you want.

When learning from mistakes either big or small, trace a few "why" back.

If you can't find a simple solution, you're thinking too complicated.

Never work unpaid overtime. Go the contract route early. Learn Python and SQL.

Next question : as an indie developer, what are my options for code review ?

I've written something about becoming a better programmer here https://medium.com/@hadalin/how-to-become-a-better-programme...

1. Read Dijkstra's material: - learn about contract oriented programming, pre- and post-conditions and invariants 2. Learn about functional programming and lambda calculus 3. Read Joe Armstrong’s dissertation

Get out. Save yourself, while you still can.

Read Clean Code by Robert Martin

Unless you already have a kick ass social life (hanging out with your mates in a bar or at a soccer/football match doesn't count): learn Argentine/Rioplatense Tango. It's the hardest couple dance and best suited for engineers -- for many reasons. If ballet is the assembly language of dances, tango is C. ;) AMA. :]

TLDR; I would give an eye or a hand if someone had given me this advice when I was 20.

Dont be a junior developer!

Be humble. You're not the smartest dev in the room. I was guilty of this in my early career.

Related to this is realizing that most software degrades over time, being touched by many people under varying deadlines. Assume best intentions of your teammates until you _know_ there's a endemic problem.

Read code. Don't despair if you check out some cool OSS project and a lot of it is going over your head: pick another project or start consuming the code in small chunks.

Don't engage in bikeshedding.

Don't be an asshole.

Always be able to explain _why_ you: picked that solution, developed it that way, favor X over Y, etc. Explain your thinking.

The "right choice" is typically right at the time the decision was made; time will usually erode that "right choice" until it looks wrong.

If possible, document the reasons why critical/large decisions were made in the project/codebase (e.g. "we had to do this like X since system Y wasn't compatible with system Z at the time of writing").

Think of the next developer to touch your code. Think of you touching your code 8 months from the time of writing. Both will help you documenting the "whys" of your strategies if it may not be abundantly clear.

Follow coding conventions of everyone else at your company; don't try to buck the standards.

Don't be cynical. Don't be a source of constant negativity. Those people suck to work with.

Find programming forums/message boards and consume at least a few times a week.

Don't obsess over picking the "absolute right solution", pick the one that sucks the least given the information on-hand at the time. If it's a big choice, document why you made that choice.

Do not burn out. If your company commonly features "death march" projects, seriously consider leaving. I suffered a nervous breakdown around 5 years into my career by working 60-80 hour weeks for months on end while dealing with veiled threats about all our jobs. This was during an economic downturn and an especially hard time to find dev jobs, but I still think it would have been better in the long run to leave. I believe our company, knowing the tough local market for devs, intentionally grossly overpromised on a deadline to a huge customer because they knew many of us wouldn't have many options. I probably made less than minimum wage that year, never did the math.

Related: in many cases, the company is not loyal to you at all. Do not devalue yourself for loyalty to your company.

Always, always give credit where it's due. Never take credit for another's work or ideas.

One of the best things you can do for teammates is relieving them of stress and sharing the burdens; leave no one on your team behind (metaphorically). This obviously depends on how close-knit your team is, but there were many times I stayed late to help a close teammate with a production problem that technically I wasn't directly involved with. When they did the same for me, I was very thankful to have that other set of eyes, the person to discuss the problems out loud. I know together we solved those problems quicker, to boot.

protect your hands. it's really bad if you lose some dexterity.

Don’t use Sublime Text.

Always test your code.

Work on things that are interesting to you, if you are bored for too long your skills will atrophy. If you are interested in your work, being indispensable to your company will be a natural result.

Start learning about the following topics: public speaking, leadership, health/fitness, sex/relationships, personal finance, investing, business/entrepreneurship, marketing, and copy writing.

Where to live, what apartment to live in, where to work, who to become involved with, what bed to get, etc.

Nootropics. Cognition enhancement. A multivitamin + D & K + chelated/TRAACS magnesium supplement. Meditation and/or brainwave entrainment audio. Stress management. Ensure quality sleep.

Nootropics that increase verbal fluidity tend to be great in corporate environment, especially as it becomes clearer what leads to a promotion/raise.

Being promoted every other year (0 = entry, 2 = mid-level, 4 = senior, 6 = staff, etc) is conservative/typical/traditional. Fast risers get promoted every year. Move around, especially if your job isn't great or well-paying, to maintain a pace.

Though an engineer, still network. Weak ties are better than deep friendships when networking. Approach all as though they are friends. No need to let someone draining waste your time. Cast a wide net, but choose wisely.

Don't let them work you to the bone. Startups fail 98% of the time (78% if BS exits are included) and corporations typically don't care about you.

Your employer owns everything you develop on company time or using company equipment.

Understand the business, users, and political landscape at your company. Avoid getting involved in politics and gossiping. Commit to maintaining ethics and professionalism, then set everything up such that it doesn't sabotage you.

People tend to be selfish, two-faced, and unconcerned about you. Smile and be happy while remembering they'll likely stab you in the back with little hesitation.

There's being irreplaceable and there's them knowing/thinking you're irreplaceable. Only the latter matters.

Many years ago, it was estimated that 4% of executives/CEOs were psychopaths (versus 1% of the general population). A study released in 2016 now puts the estimate at 21%.

Read, read, read, read...

Avoid stagnating and blindly following whatever's said. Things change and the world has little problem leaving you behind. Staying fresh/competitive can be difficult, especially as many companies heavy-handedly try to push you into the trap.

Take-home salary: 20% to savings (max out 401k even if just up to company match), 30% max to rent, and 50% toward expenses.

house_price <= 3 * yearly_salary. 20% down payment. mortgage <= 2.4 * yearly_salary.

Car: down payment >= 20% of car's value, finance period = 4 years, principal + interest + insurance + license + registration + gas + maintenance = 10% of one's gross monthly income. Buying without taking a loan is even better.

Ageism. Software Engineers have an expiration date. If not in management or a founder/consultant by mid 30s, things can easily get difficult.

If you’re the smartest person in the room then you’re in the wrong room.

Peer Reviews (PR’s) are not a personal attack on your competency, but constructive criticism and if they are genuinely toxic reviews, speak up and point it out to another senior or manager.

Write a LOT of unit tests, a good bunch of integration tests and enough end-to-end tests. You'll be more confident in refactoring and with your developer experience in general.

Blog about your work, things that you have learned etc. It will not only act as your personal knowledge store it will also lead to unexpected opportunities/connections.

I’m not a “senior” developer but what I try to improve on is always my people skills not tech skills.

I’m not an algorithmic genius don’t get me wrong, that part doesn’t appeal as much to me.

Learn and act. Doing something real with what you learnt and you will grow while you are building it. Also keep refreshing yourself with the new technologies and trends.

Develop as a hobby on a project you can get passionate about and continuously learn the stuff you don't know and look ahead to the future to get ahead of the curve

Communication skills are as important as programming skills. It is a super power to be able to communicate clearly and appropriately for the circumstance/audience.

Make sure you don't stay in the same position for over 3-4 years. Make sure you get promoted or look elsewhere.

IMO: Being too comfortable in the same position is not good enough

Don't be afraid to ask questions or admit that you don't know the answer to something.

Asking questions like "How does this work" can be the fastest way to learn.

Learn the plumbing behind the abstractions/magic (say you're a Rails developer, you'd learn what hashes are and how they work, how SQL works, etc)

Don't be afraid to ask questions and find the end of your knowledge quickly. It's better to annoy an experienced developer than to accomplish nothing.

Have the mentality that what you are going to code will be used for at least 5 years, that helps in improving coding patterns, tests, corner cases, etc..

Polish your communication skills. Writing in particular. It will help you, and help others, when you explain yourself or create documentation.

In tech, there is no such thing as a stupid question.

Read books!

have an exit strategy. development is something people are passionate about in a love it / hate it way. it's a hard job. that means you have to be able to get out of it someday. sure you might be promoted, but that's not within your control. so i saved, i bought a cheap to rent out most of it to roommates. in a few years i wont be doing it for the money anymore.

My advice would be, if you can, find your calling (something that really excites you) and then use that to learn as much to follow it.

I always tell new developers to write the comments first. It forces them to think thru the whole solution before jumping into code.

Tech doesn't exist in a vacuum, so do not ignore the board room politics! Source: senior sysadmin who learned this the hard way

Trying to make humans do the things computers do well is very difficult.

Trying to make computers do the things humans do well is nearly impossible.

I had written this before [0] in a very different context but still relevant to your question.

1. Think Big. I have seen many people who aimed higher from the beginning and did manage their way up (e.g., becoming a VP in just ten years, that too in a large company).

2. People skills is a must. You should be thinking of people or organizational challenges all the time, or you'll miss the mindset to rise significantly up.

3. Many people complain about their team leads, managers or senior leaders. This usually happens because these senior are working at a higher level of responsibility and ambiguity than you are. You should rather be thinking what would you have done if you were in their position. Understand the challenges they have, by directly asking if needed. This will not only help develop your relationship with them, but also position you to develop the skills needed faster, without yet being in the position of responsibility that they are in!

4. There is a lot of entropy in any team/organization, and unfortunately also a lot of people who are increasing it. Be the one who reduces the risks and brings order to the chaos, whose judgment can be trusted. Keep in mind for this that the real challenges are often not on technology side (in other words, if you think technology challenges are more critical, you are perhaps missing the big picture).

5. Try to become irreplaceable for the team/company in your project and beyond. In my experience, this will not come in your way as [6] suggests. You must however not get limited to the tools and technologies specific to the company, or else your market value will suffer within a few years.

6. Never say (or even feel) anything bad about anyone ever, keeping Hanlon's razor in mind [1]. But then, how do you deal with the stupidity? Well, <b>their stupidity is your opportunity</b>. (I created this out of Jeff Bezos' famous quote, "Your margin is my opportunity." [4])

7. Do not let yourself be masked from political issues around. A good manager would aim to mask you [5], but that can curb your growth since you won't develop the skills needed to master and survive corporate politics while being masked.

8. There are books available today that teach you corporate politics [2-3], showing how easy it is for anyone to do it, and how difficult it is to counter. Reading these books should be a required reading for anyone aiming to go significantly high. And trust me, it's better to learn this from books or from other people's experience than learning this stuff the hard way. (The latter would be painful for one, and second, you may never actually learn.) I have read [2] and felt that I should have read it earlier.

9. Ask questions whenever you do not understand something or if your own thoughts do not align with the decisions being made. Of course, be polite in this (e.g., "I was wondering if option X also has been considered" instead of "why are we not going for option X"). People around would be happy to explain to you while also developing trust in you, and often would take the suggestion if it will actually reduce their mental burden. The sooner the better in asking questions.

[0] https://news.ycombinator.com/item?id=16490323

[1] https://en.wikipedia.org/wiki/Hanlon%27s_razor

[2] https://www.amazon.com/dp/0743262549/

[3] https://www.amazon.com/dp/0312332181/

[4] https://www.inc.com/jessica-stillman/7-jeff-bezos-quotes-tha...

[5] https://news.ycombinator.com/item?id=16488447

[6] https://news.ycombinator.com/item?id=16489904

Be humble.

I still disagree with you. The idea that you should only become a software engineer if you want to continue it outside of working hours is one of the reasons our industry is primarily made up of white (or Asian) middle class men. It's perfectly ok to do this as a job, a really good job, a career, but still a just job that you don't pursue out of work. When we discourage people who don't want to code in their spare time we discourage valuable alternative view points and create a horrible homogenous industry (despite our industry effecting just about everyone these days). Many people don't have either the time, resources or inclination to pursue more coding out of work. And sure, the techy who does loads of side projects will be a better coder, but there's a hell of a lot more to this job than coding and it's perfectly possibly to be a good engineer while only doing it 40 hours a week. We need to expel this attitude so we can create a diverse workforce, which is proven to be more efficient.

I don't disagree with most of what you say, however: If you have a (code) problem at the end of the day it's often best to just stop - maybe even finish early. When you sit down in the morning more often than not it'll seem much easier to fix, your subconscious will have been working on it overnight.

That's better than sitting there for another hour or two in the evening getting increasingly tired and ineffective, missing dinner, annoying your partner, etc.

The statement is if you are "the smartest person in the room", not "the smartest person in the room in one narrow area". If SMEs, PMs and Sales people aren't smarter than you in some other areas, then you are somewhere with incompetent SMEs, PMs and Sales people.

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.

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.

Understand key concepts in the (web) framework you are using. By sticking to patterns defined in the framework, you'll save a lot of time/confusion and prevent easily avoidable problems that accrue debt well into the future.

Example: Junior is confused by where to put a new file/module/function in a frontend app and the app is built with Angular. Angular has Models, Components, Directives, Services, etc (I don't really use the framework, but same applies to Rails with MVC, Concerns, /lib, etc).

Learn your framework's constructs so you can frame your solutions in terms of the frameowork. You'll be more productive by reducing the scope of your decisions. Downside: you won't be able to find the 'best' solution to your problem - you are constrained by the framework's model of how a webapp should be built. This is ok, you are learning the ropes, so an increase in productivity is worth the constraint in freedom to choose.

First, imitate and understand why the framework does these things and what problems it means to solve. Once you've seen enough of these patterns/opinions (hmm maybe binding the view to a model manually isn't such a good idea, i've been forgeting and causing memleaks - hey Backbone days!) and have real life examples of where the patterns present problems, you'll be able to improvise/tweak/decide-yourself.

Never call yourself a junior software developer - fight to keep “junior” out of any title.

Read books/practice software design patterns and learn how to write tests. (Unit, integration, end to end)

All that code you write for the man you'll never see again when you leave. Limit your pride, but not your quality of work of course. This includes limiting overwork. If your financial situation and the market allows for it, find a job that is not over taxing, and if you're a programmer by hobby and have the time, write some open source stuff. Aside from career benefits, it is fulfilling to review code you wrote in the past instead of just corporate memories of it. It's extra rewarding if you're like some people that, while you improve, your past code is still of very high quality. If you're the type that relishes leaving a legacy, just be mindful of its visibility.

Good enough is better than perfect. It is also way better than 'not yet done'. Always have targets in mind. Even green field explorative projects should have targets. Good engineers ship.

Abstraction and encapsulation is overrated. Premature generalization is the root of all evil.

Knowledge is no substitute for experience.

You cannot google what you do not know it exists.

1. Don't blindly follow advice of "experts" you read.

2. Don't write clever code, write readable code. Participate in code golf or obfuscation contests to scratch the itch if you have one, but keep it out of production code, even if its a private project that you will never share with anyone; it will save you from yourself.

Program in multiple languages.

Try frontend, backend, write random Bash scripts, try multiple paradigms, try every language out there. Try multiple databases too. Don't just write toy stuff, write something substantial that takes you 2-3 weekends to complete.

All of the best developers I've worked with have mastered at least two languages, if not 3-4.

Will you necessarily use all that in the field? No, you might end up at a Python shop and decide you love programming Python. That's fine.

But you will gain so much perspective on what is possible in programming, and avoid getting stuck in the idioms of certain languages for the rest of your career. It will give you a great design sense. It will give you the ability to dive into any problem, in any language, and be successful.

A bugfix is not done when the bug disappears. It is done when you understand why it occurred and why it no longer does.

Learn how the debugger works for whatever language you use. You will be very tempted to just use logs as it's way easier and debuggers seem intimidating, but take a day out of your schedule to learn the debugger. When you really have no clue what's going on in your code there's no substitute for being able to stop your program mid run and inspect it's state interactively.

Two things:

1- Find solace in the fact that "senior" engineers often spend a significant amount of time searching the web/stack overflow just like you do.

2- Have respect for the code that came before you. Be generous when passing judgment on architecture or design decisions made in a codebase you've adopted. Approach inheriting legacy code with an "opportunity mindset".

Improve your soft skills, work is more than just coding, don't become attached to technology stacks, care about the team not so much about the company.

Never accept the title of Junior Developer.

https://daedtech.com/junior-developer-never-accept/

On the technical side, learn how to read other people's code and debug things. At the junior level, when you thing things are broken, they're probably not, but the skills you build reading and proving that the other stuff works will come in handy as you progress and you do find situations where the frameworks you use, and the languages you use, and the operating systems you use are broken.

Learn to tear down abstractions instead of building them up. As a junior developer, it may be hard to get acceptance for removing layers, but add as few as possible. Somebody is going to come through later and need to understand what you've done, when the stack is deep, that's much harder.

Don't trust other people's code to do what the readme says. If anything claims it's lightweight, count the lines of code and see. If you use other people's code and it's broken, it's going to hurt your users and you're responsible.

On a people skills level, learn how to disagree without being disagreeable. Invite people to share their reasons for things with real questions, and listen to their answers -- while they're sharing you can discuss why to do it their way vs the way you want to do it. This is a good practice for when you are the senior person instructing the junior person as well. Often the senior person is going to make the decision, but having a discussion about it can make it easier to accept.

Don't do this for everything though. Choose your battles, don't be the person who fights everything; unless you're getting good results and people are happy changing everything.

Learn multiple programming languages. It will truly expand your way of thinking about solving different problems.

Conversely, don’t spread yourself too thin. Try a lot of languages out then narrow it down to a few you find interesting and useful, then focus on learning those few.

I've got so many :(

I haven't seen this one so far (but haven't yet read all comments):

Whenever possible, try to avoid bugs. But, even more importantly: When given a bug report, FIX the damn bug. Don't:

- Shrug, mutter incomprehensible things and wish the person with the bug report goes away (yes, I've seen that. It infuriates me.)

- Say "that's not possible" (cf [1]). It is. It happened, no user makes this stuff up for fun.

- Say "that doesn't happen on my machine." Well done! Now make sure it doesn't on all the other ones, too!

- Say, "well, if you had configured it right,...". That's also a bug: Your documentation sucks. Fix it. Also make sure impossible/nonsensical configurations are visible (best done during startup, for example).

- Avoid commenting on the report/contacting the author because there's not enough information. Tell them you need more, what they must gather and how. If you tell everyone the same things, write a HOWTO and link there.

- Ignore bug reports. Valid reasons you're not fixing a bug are 1) you're currently busy fixing another, more important one or 2) you already understand the bug completely and have discussed the tradeoffs involved with others (write a WONTFIX with sound reasoning, please).

To sum it up: Be helpful to your users/admins/etc. Don't be a "Code Monkey".

[1]: http://plasmasturm.org/log/6debug/

Edit: Formatting, reference to 6debug :)

I am writing a book specifically for these. But focusing on soft skills.

Its called "self.debug - An Emotional Guide To Being A World Class Software Engineer" - you can download it here (its free) - https://leanpub.com/selfdebug

Feel free to provide feedback on twitter to me.

Invest 10% or more of your gross pay into a low cost index fund. Do this without fail for your entire career.

Never Ever Stop From Learning. The skills that you have now may be top notch and covering all of today's trendiest technologies; but in possibly less than 5years, most of these will be outdated, and your expertise obsolete. Specialize yourself, but do it everyday, on everything - try new technologies, feel free not to adopt them in your daily job, but try them. Keep in mind that every year, new guys come out fresh from school and will be as in sync with the technology landscape of that time as you are now - and you do not want to lose to them because you never took 1 hour to try the then-Docker - you want to be able to criticize the then-Docker because _you_ will be able to compare it to the past things that you will have already encountered, enjoyed or suffered from.

Please please study the tools and the principles you use. No schooling will offer these things you learn then through experience. If on your own then that takes a long time. To expedite find rules like Sandi Metz's rules and S.O.L.I.D. principles, Learn OOP patterns and code smells. Don't worry if you don't understand why these rules and principles are in place just follow them. You'll eventually get there and the code you produce will not cause catastrophes later on.

But if anything this simple rule is the best: K.I.S.S. (Keep It Simple and Small) Make small things. If you ever find yourself saying "do this and then do that" your talking about two things and make them two things (separate functions/objects) and name them.

Respect your co-workers. They may not be as talented or knowledgeable as you but learning how to interact with a diverse group of people will pay dividends down the road in ways you can't begin to imagine. And, above all, stay on the good side of your department admin.

Don't be scared of going into reading source code of libraries/frameworks you are using to understand how things work. The code will often be simpler than you think and allow you have a better, deeper understanding of how things work and empower you incredibly.

Learn sales, marketing, design, basic accounting. Basically learn everything tangential so you know why you are writing code not just how to write code. It’s a means to an end. It could be as simple as reading books or as intense as taking online courses.

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

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.

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

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.

> 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 think he is saying that he is both the CTO and the lead developer

Truer words have never been spoken.

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.

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

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!

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

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.

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.

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 :)

This.

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.

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.

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

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.

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.

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.

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

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.

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

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

"object orientation is a failed paradigm"

uh... wtf?

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.

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

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

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

try

{

....

}catch(Exception e)

{

//Do stuff

   throw new MyCustomException(“Something Bad happened”);

}

And

try

{

....

}catch(Exception e)

{

  //do stuff

   throw;

}

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

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.

Assert

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 you don't have any special handling, then why are you catching it at all?

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