In short: it’s always like this, sometimes more, sometimes less. And guess what: it’s the main part of the job. As a developer you have to understand what the customer (your boss) needs (sometimes not what they say they want) and to figure out how to do that by yourself. It’s nice to have colleagues you can ask, but it’s like on stackoverflow. The accepted answer is not necessarily the right or good one. Often you have to work with bad documented legacy artifacts (code, api) and figure out what they do. Also the tech changes, you have to constantly keep up with changes and what was great years ago may now be outdated. My advice:

• Do not start coding until you are sure you understood what is to be done.
• if there is no user story to describe the task write it yourself
• write good tests for your code. It’s an art. While thinking about corner cases you often find questions you did not think about at first
• if you don’t know how to do it ask people around you, browse the web, read books. Develop the skills to figure stuff out. Most of the time noone knows the correct answer. It’s your job to find it.
• do code reviews with others, usually both benefit from it
• write clean code

If you don’t like your working environment then change it. Especially when you think you can’t learn anything new there or it is no fun to work there. Go to meetings in your area (meetup or so) or online to meet other developers and ask them about their job. You get a feeling about what is considered a good job in your area. Good developers will always find a good job. Be one of them. As long as you think you’re a god who can code anything, that’s probably not the case. ;-) The best you can achieve is to be an expert in a very narrow field and to be good in some others.

Before you take the advice of anyone here, try to find out how long they have been in the business, because I think that’s going to change the kind of feedback you get. I’ve been doing this for over 20 years, and I’ve worked in all kinds of places, from small business, to large, to government, as an employee and consultant. Not bragging, just providing a reference point.

Your concerns and situation are ones I have experienced myself. You are not alone. I’ll give you advice I wish I could have given myself decades ago.

unsure if I was good enough

Every programmer starting out has this feeling generally. Please don’t take this as dismissive. I actually take this as an indicator of someone who will succeed at becoming a good programmer. The brazen ones who do not introspect and understand their inabilities are doomed to flounder perhaps forever.

I feel like I flip between I am a god and can code anything and omg I know nothing show me the nearest bridge.

In my experience this feeling can last for decades, probably forever, but as you gain more experience and hours of working on code, the bridge diminishes. If this doesn’t make you feel better, you’ll just have to take my word for it… it does get better and you will be happier over time. As you get more experience, you will be able to better estimate things, so you can know when something is way too big to go alone, or without more resources/support, or without more budget, and how to say so/no in those cases.

It took me a while to realize, that if something doesn’t work out the way you planned it, it’s not all on you, the business and how it functions (or not) has more to do with it than anything. Small businesses are, frankly, generally more stupid. It can be the blind leading the blind, so what hell were you gonna do anyway. They didn’t want to pay for a super team with mentors, so they get what they get, and that’s not on you. I’ve found that most of the time in business, failure happens and shit just moves on, because there are other fish to fry and fires to deal with. What you think matters, as an introspective person, hardly crosses the mind of business folk.

boot camps [said, in] your first role you would get lots of support

You have to keep in mind the source of these boot camps and what they are for. They are funded by silicon valley so that they can get as many (hopefully talented) bodies in the door as possible, to keep costs down. More supply, lower costs. As such, they are aimed at people who will work for those companies, and those companies are desperate (depending on the market I suppose), so they will definitely have support in order to retain folks.

I work for a small company < 10. I don’t feel I get the support I expected.

Speaking from experience, being a developer at a small company is generally fucking garbage, for some of the reasons you and I have touched on. They have anti developer and anti productivity practices, and they don’t care to improve. They generally don’t know what they don’t know. Depending on the place though, this can be an advantage: they don’t know enough to know that “you suck” (you don’t suck, by the way). They can also be desperate to hang on to anyone dumb enough to keep working for them (no offense. You are not a dummy, circumstances are just not in your favor yet).

the spec is kept in the […] (owners) head

Aha, yeah there’s your problem. The owner is a developer running this shit show, and I guarantee they’ve never run their development the way the software development industry would. They should know better than to run things this way; if you can’t have the fundamentals of your business shared with the team that are trying to make it a success, how could you ever hope to make it work? Some places hobble on in spite of this, but they will only have the fraction of the success they could have had if only they’d had a person with genuine vision (or smarts enough to hire that person) at the helm.

[when given a task I get no timeframe]. [the task is given verbally]. [confusing to understand their vision].

If you had worked at a big silicon valley place first, you’d have first hand experience with agile/scrum, and how it works to solve all of these common issues. This is not a criticism of you, I’m saying working at a place that has agile/scrum should be your next pursuit.

In A/S, tasks are written down in tickets, estimated, and prioritized. Effort and vision are made clear before the work starts, written on the ticket so everyone is clear on it and about the deliverables. If it’s too much effort, the ticket can be split into manageable chunks. It vastly reduces the people problems that come with managing development work by turning it into a process that can be refined according to how the team works, instead of a negotiation with a lead maniac.

By not doing/knowing about this kind of practice, your business is at risk from competitors who implement this correctly, are therefore more efficient, and will naturally out compete you. Not your problem though.

If wrong I’m not called out and they will spend a little more time going over what they want.

Good. As much as I am shitting on them, they are at least reasonable seeming.

The boss is always so busy that sometimes you feel like a burden asking for pointers.

That’s on them, and that’s business life. Honestly, IMO they need to get some of their shit together, but that’s not your place to advise or worry about. Also, they probably knew they were getting a greener guy, so they’d be expecting questions. There’s a balance between knowing when to ask, and just trying stuff, and newer people should bias towards asking, IMO. Your leader may feel differently, it seems like they’re reasonable enough you could just ask.

the newest will start as a copy of the last one

Having done this myself before, this is the path to hell, in my opinion. It can work, but it’s a shortcut and in my experience it’s a maintenance nightmare. This is not the practice of a company with vision, it’s a company that’s just chugging along for now. If you had the vision to be acquired one day, you wouldn’t do this. There should really be a core code base that all instances share, so even old implementations can benefit in the future, if need be. I’m sure this opinion will be controversial. Again, not your place to worry or talk with them about it.

[Existing code is] second nature to [my colleagues] and I feel stupid

20+ years in and it’s still like this for me when starting at a new place. The difference is experience lets you know not to worry. Practically nobody is a genius, and the geniuses are writing white papers, not code. My advice to you is to just delve into the code base and read as much as possible and follow along with how it works. If you want to get a leg up (which I would advise for a green person) do some of this in your spare time, as much as you can afford. Otherwise you will get experience with the code eventually through your day to day work regardless. Don’t get too invested in them though, you should move on as soon as possible (for a bunch of reasons).

is this normal

Feeling stupid in this situation is normal, you are just green and will be fine. The small business that operates like this is all too common, and you are not in the place to do anything about it, and I would not advise getting involved with trying to fix it. If you were an investor, then I would try to fix it. You should worry about you, not them. Use them as a stepping stone to your next opportunity.

to gauge how I am doing

Ask for a performance review. They may be too small to know how to do this properly, if at all, however. You know them, you will have to be the judge on if they will take kindly to that request. Any place that isn’t garbage should be happy to do that for you however. Agile/scrum would have metrics you could just look at to know how you are doing, any time, just saying.

there is no remote work and no headphones in the office

Here we are back to the dumb shit. They are leaving money and productivity on the table, and that is not the mark of a good business. Unhappy workers are not the mark of a good business. They might be smart coding wise, but they are not smart business wise, which is a real problem when the whole point is to make money. Imo you should get out ASAP, but that might involve sticking it out for at least another 6 months, so you have at least a year for the resume.

when is a good time to start looking for your second role

Always be looking. If I could go back in time and give myself one piece of career advice it would be this: always be looking, interview often, even if it’s just to say no, and never stay in one place more than a year or two. If I had done this, I would have been happier so much sooner, and would be making at least twice the money by now.

Do not be loyal to these folks, small businesses will cut you at the drop of a hat like any other business. For them it comes down to business no matter what.

In my opinion, for your career, you need to get on a real development team that does agile/scrum as soon as possible. Agile/scrum not a panacea, nor the end all be all, but it should give you a good reference for how well/things should function on a good development team.

You seem to have a good head on your shoulders, you are worried about the right things, and are asking the right questions. Good luck out there.

Stop overthinking it! You’re doing fine. If you get it right some of the time, that’s already better than most. The company culture doesn’t seem to emphasize documentation and formal processes, which can be a good thing and a bad thing. My advice would be to stick it out for at least a year, before looking elsewhere. As long as they pay you and you’re not under constant fire for making mistakes, everything’s fine.

Bruh, I’ve yet to find an employer that can accept me. Congratulations on getting your first role. I’ve been told that the barrier to getting in is the hardest.

all through my tech career has been the im a god, im so stupid flip flop. Its normal.

If you don’t understand the task it’s fine to ask questions, you both will waste less time

So just ask them to go in depth, or tell them what you understood to check it it’s what they want

Seems to me, you’re dealing with a micromanager.

Personal recommendation - put things into writing. When you get your assignment verbally, write it down with assumptions you have to make to fill the gaps, and send it to the person who gave you the assignment, with the person responsible for your teams’ results in CC. Basically an “I heard you, and I’m starting the work as described below”.

Communication is one of the most important skills in software engineering, and this way you get to practise it while probing the social waters of dealing with management.

Try it, see how it goes, adjust accordingly.

There are good bosses and bad bosses. Those bosses are basically responsible for the work culture. You’re in what I would feel is a toxic work environment. Sadly, this is the case for most businesses in tech, in my experience.

Ask your supervisor or boss if you can have a monthly meeting with them to help get you on track. Let them know how you’re feeling, and say you think some regular meetings could help smooth things out.

If they’re not receptive to that start finding a new job. Nobody gives raises like new bosses, and if the one you’re with is standing in the way of your success, get out.entry level tech roles are very hit or miss. If you feel it’s a miss, it’s definitely not worth sticking around. Not in this industry.

At the end of the day the squeaky wheel gets the grease. If you need help be proactive in asking for it. I can say with my team that I don’t have time to go around asking everyone if there are any issues, but I’ll make time for anyone that needs assistance to ensure they are unblocked. I also don’t want to micromanage people and annoy them when they are capable without my instruction.

It is hard to know how much information you have to give someone to do a task. Something that may seem obvious to me will require 30 minutes of discussion for some people while others like to go away and figure it out but will reach out if they are unsure about something.

I’ve been in this industry for almost 5 years and having worked at 2 different massive ( > 10,000 employees) tech corporations, I feel comfortable saying this is how the industry is. I imagine that the main difference between a company the size of yours and the size of the ones I’ve worked at is how well the systems are documented. Regardless of where you’re working, they need to be willing to help new people onboard and onboarding people need to feel welcome and comfortable asking questions. I’m currently almost at 2 years at my current company and I still have to ask questions all the time. The people I ask sometimes seem annoyed with my questions, but they never seem to think it’s bad that I’m asking questions, and that’s good.

I think you ought to ask for better communication at the outset of your tasks, and if they’re upset by that or tell you it’s your job to figure out what you’re supposed to be doing then that indicates they’re not interested in building a team and it is never too early for you to start looking for a different job in that case. Any reasonable recruiter or interviewer you talk to should understand that’s a great reason to jump ship.

I have never been in a company that had it all.

I was in one with all of the proper setup, fucking 10/10 CI pipelines, tests, the works. Someone just made stellar templates. 0 documentation tho and if you need to launch something in dev, get fucked. 0 task management, minimal meetings, barely a trello, and often you’d be like “okay what I do now?”.

I don’t know who gives that advice. But from personal experience I’d say it’s like this in most companies. Everyone has a job to do and tasks to finish. Nobody has extended down-time to train ‘the new guy’. Especially the experienced people you’d like to learn from have important stuff to do.

Some employers like their workers to actively solve their problems. So you could try to be more proactive and vocal about it. Say you’re not familiar with that project or tech and you need a more detailed explanation. Tell them what you didn’t understand and ask where you can look it up.

Hey bud, I’m in the same boat.

I’m in my late 20s, been coding since middle school. Worked in the industry one way or another for 7 years or so.

Sadly you’re experiencing the reality of small-medium sized companies.

For the vast majority of my “career” I’ve been flying solo on my projects. Guessing what my boss/the customer means when they tell me what they want.

My advice is this: finish whatever project you’re on, or bring it to a point where you can reasonably hand it off. Use the remainder of your first year to find a new employer.

Try to go for a bigger company rather than another small one. Corporate bloat is annoying but there will be structure, seniors to help your skillset develop, code reviews, specified requirements etc.

Good luck!

Yeah, that sounds pretty normal, I guess. The time-frame part is probably based on how new you are as well as the nature of the task. I did quite a bit of that type of thing when I started, basically fixing tech debt, and small stuff.

If it’s something you want to bring up, I think you expressed yourself pretty clearly. You could schedule some time with your boss to talk about it.

What would frustrate me would be the rework I was doing. If you could maybe even set up a short weekly meeting? Show your boss what you’re doing and they could tell you if it’s the right track or not.

90% of my career as a software engineer and cloud architect over the last 15 years has been figuring it out myself. It’s great when there is a senior super coder with free time to mentor you, but that was literally never the case for me, I’ve been the most senior on every project I’ve ever worked.

It means I had to learn a lot of things the hard way, but I also think it made me better at what I do. I now mentor jr devs to try and save them some pain, but what you’re seeing, especially in a small company where people wear a lot of hats is pretty normal.