Hacker News new | ask | show | jobs
Ask HN: Am I incompotent for web development?
60 points by m0xai 1455 days ago
Hello,

i am a foreigner Bachelor Student (Business Informatics) in Germany (came a half year ago). I had experience with HTML and CSS. One and half year ago, I decided to learn JavaScript also. I completed FreeCodeCamp course and The Odin Project. My Portfolio was enough to get my first working student job as a web developer on December 2022.

I then started with Tasks like removing the BootstrapVue UI Library and replace with regular Bootstrap in small projects. That took like 60h, because I had to learn vue first. My colleagues said but nothing negative about my work.

Yesterday was for me like disaster. I worked until 22 o'clock, (I had to stop at 17 o'clock) to find out that I'm running a microservice in a Docker Container and the changes I made on a mail template had no effect, when I send them, since I was working on local files. I feel myself an idiot and can't tell anyone.

Am I doing the right job? I can surely say, that I love frontend development and also backend with java and Python. But loving a theme is enough to do it as a job?

Edit: Thanks for all your comments, all of them very supportive and made my day better. This long-time failing experience is the first time in my life, so maybe I had to live and deal with it. And yes, I love what I do and how I feel. For me there isn't any better feeling, after fixing a bug/completing a task. From now on, I will reading the docs more and not trying hunt the exact answer on stackoverflow at first place.

35 comments

I'm sorry you're experiencing this level of stress. The situation you're in is one that many (I might even say most) junior, and even senior, engineers find themselves in. If I can give you one piece of advice that was critical for me, which I share with every new engineer, it is this:

Be radically transparent with your team when you struggle. Tell people when you're stuck, when something is new to you, when you're uncertain of where to go next. And tell them soon.

In my first jobs, I constantly felt like I was "interviewing" for my position even after I started. I thought that if I couldn't do something simple, I wasn't living up to the skill level I had promised them when they hired me. So I would hide the fact that I was struggling. Worse, after 2 days of being stuck on something "simple," I'd feel like I couldn't possibly tell the team--they'd think I'd wasted their time for two days!

The key for me was to simply be transparent. If I was assigned a task that used some technology I'd never seen, I simply told the team upfront "Hey I've never used Vue before. I'm going to read the docs and familiarize myself with the framework, but if this is particularly time-sensitive, should someone else take this ticket or can anyone recommend a better approach than learning Vue from scratch?"

Then, whenever I hit a confusing bit of Vue code that I couldn't decipher in 20 minutes, I'd simply post a link in Slack and ask "Can anyone help me understand what's going on here?" and explain where I was getting confused.

If your team hired a junior, they don't expect you to be a senior. If they see you working, see where you're getting stuck, and see where they can help, things will go much more smoothly. Where conflict occurs is when a junior disappears for 3 days, then shows up with a PR that needs to be redone (speaking as a person who has been that very junior).

Please listen to this advice! I’ve managed hundreds of developers and i can tell you the difference between someone junior that we keep and someone we exit is substantially defined by how good they are at communicating their circumstances and allowing others to help. People make the mistake of assuming others are too busy or will be annoyed, it may seem that way but they would much rather you ask than not be productive.

Ask questions. Tell people where you’re at. Advocate for your own success and by all means, do not ever hide problems or the challenges you’re facing. If the team cannot support you when all you’re doing is being honest, that’s a problem I’d solve by finding a new team to work with.

100% - The #1 developer mistake is not knowing when to ask a co-worker for help. Juniors make this mistake more often, but I've observed the same pattern in developers with lots of experience too.

When to ask a co-worker for help: domain specific problems, open ended questions, subjective questions that would be hard to input into a search engine, etc.

Ask questions when you would spend a lot of time tracking down the answer. Don't ask a co-worker a question that a web-search could answer quickly.

Also, if you do go ask for help, tell them what you already tried (and you know, actually try some things, even if that ends up being a waste of time).

I love helping people that have put in the effort to try doing something themselves, but I hate helping people that just dump their work in my lap.

The “I tried nothing, and I’m all out of ideas.” trope.

The guideline I always tell to juniors (and I can't remember where I read it) is that if you don't spend 15 mins on it yourself you're wasting others time, if you spend more you are wasting your own time. After a few times of breaking that rule both ways they usually stop asking before trying to find the answer themselves but also sometimes feel more free to spend more time on something if they want (since it's your time).

Of course 15 mins is meant as a loose time, as a sort of benchmark for "give it an actual try yourself, but don't spend a day stressing out yourself without help".

Thank you sir, I read this and thought what I did all the time. If I was more transparent, maybe I felt better and could think without stress.

This means to me that talk with my project managers and colleagues more make more comments/updates on Asana :)

so leetcode grinding doesn’t work and maybe experience is more important then, after all?
I imagine it's patently obvious to everybody that leetcode grinding tells you nothing of value. I question the actual experience of anybody that didn't find that out yet.

I believe people put it in interviews because they need some metric, and hey, it's a metric. Quite like the constant attempt on estimating the work done on some software.

yeah, i guess that implies that management are a bunch of incompetent idiots.
Personally, I'd be happy to see a single place where management doesn't do the "we need a metric, this is a metric" dance in some context.

Anyway, it's hard to say somebody is an incompetent idiot when literally everybody does the same thing. It's certainly caused by some structural feature of companies.

I thought leetcode grinding was just for passing the interview, not the actual job?
experience seems to be far less important than leetcode BS in getting hired. experience is really all that should matter.
Allow me to give you an internal perspective:

Web development is hard. The individual parts are manageable, but bringing them together is a mess. We web developers are aware of this. It's like an open secret.

And it takes time getting comfortable with the mess, and letting the brain develop its own map of how things work. And you will do stupid mistakes along the way. Those are funny actually.

I'll give you my current perspective:

I've been at this for a decade, and I am definitely not incompetent. Last week I spent the night fixing a seemingly simple bug. It ate up my night and sanity. I went to bed angry. Woke up, are realized that I was looking at the right service, but editing the files in the wrong folder. Of course I didn't see the output. And I couldn't stop laughing.

This sort of silly mistakes happen almost once every month.

It can be frustrating, it will be. In webdev, things are in constant flux.

But try looking at it through a sense of humor, and you will see how funny it all is. The mentality will carry you through the decade.

We are just anxious & weak monkeys, with big brains, worrying about glowing glass powered by stone with lightning. It's surprising we even made it this far.

You and I deserve the leeway to make some mistakes for ourselves.

Oh, that reminds me of an entire day I've lost recently trying to find the error on a personal project because the "deactivate cache" checkbox wasn't marked on my browser. Yes, the web is complex.

(I have about 30 years of programming experience, about 20 of them professionally, a CE diploma, a post-grad in machine learning... All of those gain me ability of not keep wondering the thoughts the OP had, it doesn't save from the stupid mistakes.)

I’m be Doing web development for 17 years. I’ve been through all kinds of frameworks and paradigms.

Most recently I’ve been learning Typescript (finally) as in my new role, _everything _ is written in it. I described it like a toddler. Every time you do something it says “why” and then you explain and it asks “why?” About your explanation.

The advice here is good. Communicate with your team. If they’re worth their salt they will respond with support and good faith.

I've suffered from "are you connecting to the right database" enough times that I can often psychic debug that problem for others given a couple of lines.

Make a mistake enough times and you start to be able to smell it.

I did laughed also so hard, that the problem with the mail template was the missing end tags of inner table. And at the end I can say that I was very happy, even if I spent too much time to figure out the docker thing.
The cognitive overhead for coding web apps in a modern enterprise environment is enormous. It tends to be a big pile of spaghetti where the hipsters changed the noodles to the RPC flavour and called it "microservices". Most times it's poorly documented, haphazard and impossible to test without connecting to the whole zoo of service dependencies.

It's not you, it's them.

If you want to do web dev you'll have to put up with this shit as most places do not want to return to sanity because somehow I'm being told that the cloud "empowers them to go build faster". Nevermind the evidence is sorely lacking but this is how they all roll. From 40 person startups to Fortune 500 they are all cargoculting hard on microservices and cloud. Developer experience has taken a complete backseat and fighting for it is a real uphill struggle.

I feel like this is a "you are not google" shaped problem. Even most Fortune 500 companies aren't.
Nothing you say suggests that there's anything wrong with you. A lot of this job is knowing stupid details, and once you get to tools like Docker, what's happening under the hood is actually quite complicated and there's a lot to understand. You just don't notice except when things don't work. It takes a long time to get really familiar with one stack, and even longer to learn enough to fully be able to connect the dots.

One thing I try to remember when I'm mashing away at some dumb thing for hours that I don't understand (8 years in, it still happens a lot), I try to leave it for an hour or till the morning if possible to clear my head, or better yet I ask a co-worker to let me try to explain the problem. Sometimes they can help, sometimes just talking about it to another person is enough for you to discover what's the actual issue.

> I ask a co-worker to let me try to explain the problem

This is a magic power, 4 times out of 5 in my experience telling someone about your issue resolves the problem or confusion.

Well in my first couple of weeks as a professional dev I managed to wipe the production DB with a dodgy SQL query so you're probably doing better than me (=

I think most people here can relate to this though. There are still times I'm working on something and think, "oh god, I'm in over my head here". And I'm a senior dev so I'm paid to know what I'm doing.

I agree with what another commenter here said about being transparent with your team. As a junior dev no one is (or should be) expecting you to know everything. Even senior devs can't be expected to know absolutely everything. I still ask my colleagues to help me out with things almost every day and similarly they ask me questions too.

You're expecting way too much of yourself and stressing yourself out. It's okay to not know everything.

I think we've all done something like that.

I try to insist on my production account being readonly and having a separate user for deploys.

You know what makes a senior dev? They've already made all possible mistakes and learned from them. You're on the right path.
I'm very senior these days. Most of my job appears to be unsticking people. But even I get stuck plenty, and while I can quickly unstick most problems the other devs face I can't solve all of them.

Getting stuck still happens. The real difference between what I face now and early in my career is that I have developed a sense for when to plow through, when someone else might know the answer, and when to route around.

Plowing through usually means it's not worth interrupting someone else. Or when the business itself, or other teams are in the way.

Asking questions because you don't know requires humility and it's best to have it even as a senior. Just ask, and do it sooner rather than later. You will learn faster than banging your head on the wall - there will be plenty of other problems to do that for.

Some problems aren't worth the pain. I could solve this, but should I? It saves the business lots of money to occasionally route around the problem.

I often talk about a type of pattern recognition with this sort of stuff.

Over time you start to develop a sort of automatic pattern recognition skill that separates problems to "I've never seen this before" and "oh, this looks very similar to x". Also it becomes much easier to know what's hard and what's easy, like you said.

You still obviously make the wrong call here and there. More often if you're in a completely new field, like the OP.

I phrased it upthread as "make the same mistake enough times and you can start to smell it"
100% this, my statement was short therefore very incomplete :)
Then being a senior web front-end developer is like living within a mistake.
This is not right but good advice ;-)
I’m going to say exactly the same thing as others here: getting into situations like this is part of the job. It’s not a very fun part of the job, but it always happens and it happens a LOT in WebDev.

In particular, it still happens to me after 25 years and yeah, I ask someone for help. Being a fairly experienced dev, people are often asking me for help, but the road never stops running both ways.

Agree wholeheartedly , especially in Web development and JavaScript.
What you describe is pretty normal, so stick with it and don't be too hard on yourself.

Don't be afraid to ask for a second pair of eyes though.

Often the teddy bear effect of you having to explain what you are trying to do will make you see the solution immediately (ie. why are my changes not coming through ... because I am editing the wrong set of files etc.).

> Yesterday was for me like disaster. I worked until 22 o'clock, (I had to stop at 17 o'clock) to find out that I'm running a microservice in a Docker Container and the changes I made on a mail template had no effect, when I send them, since I was working on local files.

I am a senior IT architect with 10+ years of industry experience. Just this Friday, I was debugging an issue in a Docker image together with a colleague, and we were completely baffled why none of our debug output was showing up when we ran the test job in the CI on the Docker image. After half an hour, we realized that we had been pushing the image into the wrong repo, so the CI never picked up the changes.

It happens to everyone. Don't sweat it.

> From now on, I will reading the docs more and not trying hunt the exact answer on stackoverflow at first place.

When mentoring, I always encourage my juniors to take time out of their workday to just read up on things. If you're going to have to use a difficult new library, give yourself an hour or two to just read the documentation on that library to understand the principles on which it is based. Even if you don't have any specific new technologies lined up, maybe take the time every once in a while to just read a random manpage. You don't have to memorize everything in there, but just getting a vague comprehension of what all these tools that you use are actually capable of. Once you run into a situation where these capabilities can be useful to you, you might just remember reading about it somewhere, find the relevant part in the manpage, and save yourself some time hunting on SO.

"Reading the documentation end to end" is a superpower.

Some documentation is a bit large for this, but less than you think because it gets faster with practice.

I'd also mention "don't be afraid to source dive on OSS stuff", you'll be slow at first but being able to jump into other's people code and mentally reverse engineer their intent/architecture grows with time and is also a superpower.

(to the point where I often read the code first then check the docs and/or the tests to see if what I plan to do is explicitly supported or just incidentally going to work)

Do you have any previous experience with programming? Because if you don’t, leaping from HTML + CSS to JavaScript is a huge task. JS is programming, the others aren’t. I know people tend to put them together because that’s the regular FE stack, but the learning curve and skills required to do JS are way different than the other two. So I think you should just keep at it, but also keep in mind that JS is a programming language and you’re essentially learning a whole new thing there.
> keep in mind that JS is a programming language

It's more than a programming language; it's a really big programming language, with quite a lot of backward-compatibility cruft. There are many ways you can use Javascript, but should not. I've been writing Javascript for years, but my JS code isn't fluent, stylish or even modern.

Before I retired I was a senior; but the fact is, it was the youngest guy on the team that was the best at sizing-up Javascript problems - so I would in the end rely on him. But I would first hit the problem with my head until I had a headache, not wanting to waste my teammate's time.

My teammate was actually interested in Javascript; he would go to classes and conferences. I wasn't - I never liked it. My strengths lay elsewhere.

HTML and CSS are programming languages too—documents in those languages are declarative programs for the browser’s layout engine.

The way one writes their CSS selectors against their HTML structure has huge real-world performance implications, but people rarely care to think about what actually happens under the hood as a browser parses their documents and generates an image on the screen.

I agree that HTML + CSS are very different, but why do you say they aren't programming?
Bad wording on my side, but I think you get the point.
You can’t imagine how many incompetent developers are there making good money and not feeling a bit of shame. Just go use long enough every other popular software (camtasia, google search to name a few examples).

So don’t worry :)

But seriously the fact that you care about your professionalism alone puts you on the next level above the army of bad but self confident developers.

I wish you to use it as a tool for your growth, not for feeling bad.

You have imposter syndrome which is normal. You’re just beginning your career and it’s normal for you to feel like you’re falling short compared to more experienced colleagues. The best thing you can do right now is be honest and vulnerable to your senior coworkers (unless they’re assholes). Finding good mentors and getting feedback is the best way to quickly level up your skill set.
> (I had to stop at 17 o'clock) to find out that I'm running a microservice in a Docker Container and the changes I made on a mail template had no effect, when I send them, since I was working on local files. I feel myself an idiot and can't tell anyone

This is not your failure. This is your team's and your manager's failure. They should be aware about your knowledge levels about the application you're working on and provide this kind of information before hand instead of leaving you flailing around. I would be more upset at them than at yourself, but sadly a lot of senior developers have the empathy of a bag of bricks.

Don't be ashamed of the amount of time it takes you to find solutions, acquiring knowledge is not always a straight path. The important thing is that you learn.

It’s definitely not you but the system. The experts who say negative are narcissistic as they should actually be helping. Negativity is the death of team work.
Argh. We all have these stories of lost hours because of an assumption that proved to be wrong.

Nowadays, whenever I help someone debug an issue, I insist on starting from zero assumptions (by making self depricating jokes, and stating that I need to understand the context properly).

Furthermore, the culture/way of communicating in German might a _lot_ more direct and interpretable as negative than in Brazil. I'm Dutch, and we're known for our directness, but I've ben upset by some Germans before by how negative they can be about some work. They didn't intend this at all, they were just unaware of how their communication landed.

Just one more thing to consider: the OP (and you) might think that the negative experience is due to different cultures and that is certainly possible.

However, we also need to keep in mind the possibility that he/she is working with negative people, that are simply a*holes. If that is the case, I'd recommend looking for a new team.

I'm also an immigrant in Germany and so far my experience has been positive on most teams, so if someone feels that a team is hostile, negative, belittling, don't stay there too long only because "I must be too sensitive and I can't handle how Germans communicate". It's not always your fault.

Agreed! And in any case, if the company culture doesn't suit the OP, assholes or not, don't stay. This can be a huge energy leak. I realized this only too late at one of my previous jobs.
Nobody learns new technologies as quickly as you seem to expect yourself to learn them.

What you are describing sounds pretty much what I would expect a jr developer to struggle with. The key, as mentioned by others already, is to ask for help proactively.

If you're not getting help after asking, that's when I would start to think about whether I'm in the right place. Not because of my skills, but because if your employer doesn't support you properly, your likelihood of failing in the job goes up dramatically. This is especially important early in your career. Don't stay at places that don't properly support you.

YOU’RE DOING IT RIGHT!!!

You’re paid to not stop until you have a competent solution.

Self as an obstruction as very common. Take breaks, EXERCISE, don’t eat junk food (it corrupts your mood).

Keep solving problems!

It is the persevering mind that endures.

The situations you describe are “as-hoc”. You’re thrown into the middle and expected to tread it out.

Judge yourself by your own doings, not your adaptation to the toil with the doings of others.

Don’t forget to intelligently ask for help. All the time a fresh eye reveals something, and to get (small discrete units of) help from others is actually a good way to make friends. Everyone likes to share how they would fix the problem.

> to find out that I'm running a microservice in a Docker Container and the changes I made on a mail template had no effect, when I send them, since I was working on local files

A couple of decades of programming in, and I could still very easily make this mistake if I started working with Docker, because I’m not familiar with it. I would pick up on the problem much faster than you did, but that’s because I’ve trained my intuitions over the course of many years, not because I’m cleverer—through experience, I know that if a change doesn’t seem to take effect, it will be either that I touched the wrong thing (edited the wrong file, talked to the wrong server, ran the wrong program, whatever), or that there’s a cache in the way and I need to recompile something, restart something or clear some other kind of cache. You don’t yet have this experience. Persist, and you’ll pick it up over time.

As a more personal suggestion from my own experiences: if you possibly can, find someone that seems to actively enjoy explaining things and get them to take you under their wing. Most people aren’t like that, but there are a few here and there; I’m one, and I love having people ask me things and getting to explain them to them, and watching them grow. (And if you’re an introvert and worried such a mentor will wear you down with extroversion: don’t worry, I don’t observe any correlation between extroversion and enjoying teaching.)

Web dev is in a state of shit where devs are pushed towards increasingly complex and fragile stacks. The fact that you're learning Vue, micro services, docker and god knows what else just to do front end is sad and doesn't reflect on your competence or ability.

Eventually you will learn this stack but unfortunately be forced to learn a new one fairly soon. That's the real challenge with web dev: are you ready to do old stuff in new ways because trends change so fast?

Agree with this web view. It’s a dumpster fire of absolute garbage peddled as engineering. Sprint planning validates it as there no time to highlight the garbage being generated under the guise of software development. The key skill for this work is efficient use of google and copy/paste. This is the end game of where this whole malaise has ended up.

I don’t know how software development recovers.

The web has always been bad, just never quite so complex. The stacks are more complex and fragile and I would argue fragile because of the complexity. Most of these tools are intended to improve developer experience but I have yet to see evidence of that. I'm just glad I'm mostly working with C++ these days.
Aah this reminds me of my early days in software development. One time i had to recompile qmail over and over with debug printfs just because i couldnt figure out why it didnt work. Spent two weeks on it. Turns out i had the wrong permissions on a directory. Felt like an idiot. Could have used strace or something better instead - or heck i could have the manual! I still feel like that when i pick a radically different to what i am used language. 7 years ago when i first tried Haskell i thought to my self: “bro can you even code? what am i even doing here?”.

Fast forward to today and i usually get a “feeling” about why things might not work, and dont even need to dig deep to figure out why, i just “know”. Thats called experience. Comes with time and practice. Gradually you develop a sense to why or how things should work, and thats why experience is valuable.

So give yourself time. And sleep - sleep sometimes lets your mind work on solutions, hence the expression “we’ll sleep on it”.

I've been paid to be a software engineer for 15 years, and played with computers for years before that, basically from the day my parents brought one home when I was a kid. Everything I've ever learned has come from failing. Really, everything everyone has ever learned came from failing. Don't feel bad when you're struggling, just remember that on the other end of it is something new to learn.

Loving a theme is absolutely enough to do it as a job, but you may have to work at it - and that's ok, great even! Just remember that your colleagues were new once, too, and someone probably said negative things about their work as well. Sure this comes easier to some than others, but that doesn't mean that only those people should be allowed to do it. Some days are productive, some aren't. Just try to make your average score more towards productive, and you'll be alright.

Tomorrow is a new day. Get some rest, take a breath, and get back at it.

You like development work and you are willing to learn and to put in the hours. Putting into practice what you have learnt in real-life situations is always going to throw a few spanners in your way that you can't possibly avoid without prior experience. Don't worry about it. It's not you, it's life. Don't beat yourself up about it.

Try learning through socialising, too. Reach out socially to rookies with whom you can share tales of woe - and maybe laugh together about them, and congratulate each other on the experience gained from them - and reach out to experienced devs who are willing to mentor rather than criticise you for understandable mistakes that they've probably forgotten they used to make themselves.

I truly doubt that you are incompetent, and I know for sure that you are not incompotent, and I really hope that you don't mind a bit of wry humour ;-)

Best wishes on your path to confidence and success.

I started out building websites as a hobby in about 1996 and somewhat professionally in about 2001. I’ve worked on many different web projects over the years, using various different platforms, frameworks and libraries. After 20-25 years in the game, it’s really only been in the past 3-4 years I’ve really felt like I’ve known what I’m doing. Even now stuff still throws me.

So, don’t be discouraged. Don’t think you’re stupid/incompetent for not knowing everything yet. It really can take a long time to understand how all the parts of the stack work together.

Aside from continuing to improve your craft, think about how you can improve your relationships with your colleagues so they become more supportive, or consider leaving and finding a workplace that is more nurturing to less experienced team members. Such places do exist and it’s worth making the effort to find a workplace where you feel supported and valued.

Good luck to you.

Most software development work involves maintaining existing systems, each of these is unique and requires you to learn the details of a particular system and all the tools, libraries, frameworks, etc. used by that system.

It’s is a lot to know and all of us who do it have stories like the ones you tell.

These sort of mistakes are the kind of things you will laugh at a few years from now. E.g thinking your sending data to one location to only find your pointing to a totally different location. Learn, grow and accept even in later years you will still make similar type of mistakes.
It's worth considering getting a coach for some of your skills either within or outside of the company. The reply about transparency was perfect. But you also want to be able to develop without necessarily always feeling like you're pulling at the team. Someone who isn't part of your company that you can talk to and get advice through problems will add cool perspective to what's happening too. Don't underestimate the people around you suck. Plenty of "seniors" are actually junior by ability but get hired, and hide it by shoveling work and zero support on others. There are often volunteer orgs for getting a coach like https://codebar.io
If you really LOVE what you do, it shouldn't be a problem, because you will able to learn and improve as much as needed.

You just need to accept the fact that this profession is all about learning all day every day and solving problems. If you like doing that, doesn't matter what is your current skillset, you will definitely improve and will learn these things over time.

Also everybody makes stupid mistakes, don't worry about those.

Also it's way harder to start today than let's say 5 years ago, because there is so much more technology to learn, so yeah it's a rough start, but you will enjoy more as you learn more.

I've been doing web development for more than 20 years and it has become more and more complex. Also, people's expectations for sites are higher (sometimes needlessly - intranets don't have to have state of the art design, but I digress).

It's difficult for one person to be really good at the whole stack. Since you are a beginner, I would recommend you to concentrate on one part: frontend or backend or infrastructure. With time, you will gain confidence to meddle in all areas.

It is a tough job and maybe you should find another company where you can get better colleagues.

You will do many of those stupid mistakes in the future (take it easy, your palms are already sweaty then), i say that with confidence since i drop'd a database midday (insurance company) on the production system instead dev (just one of my ~many proud moments).

Just have a eye, or try to implement strategies that this ~cannot happen again.

Wo gehobelt wird fallen spaene ;)

Sounds like a typical workday during the first few months of a software developer's carreer to me.
> My colleagues said but nothing negative about my work.

I can read this either as "my colleagues said nothing but negative about my work" (what most others seem to be reading) or "but my colleagues said nothing negative about my work" - are we right in assuming the first?

> Edit:

Keep at it :)

I'm sorry for my bad English, it became worse, when I learned German last year :) My teammates are very kind and they are supportive. But I'm the only Front-end dev in my small team. I ask for help from people, who works in other teams. Almost everyone when I ask something, they help me/show me the right way. But I chosen to not ask often questions to hide my incompetency :) Here I understood that it was clearly a mistake. I have to be more transparent, especially now, at the beginning of my carrier.
No need to apologize - just keep in mind that some replies are written believing your colleagues are criticizing everything you do. Doesn't make the advice less useful, but it can affect the sentiment.
A HN post is not enough to evaluate your strength. Link to some web software you have written and uploaded to GitHub or other source code sharing site and I will tell you what your strength is in comparison to your age cohort.
When you feel incompetent (as you do), and you get the feedback from being incompetent (as you have), you probably are incompetent. That said, you can always improve. It's first job, its whatever.
Anything is hard when you are not familiar with it.

Be nice to yourself and don’t expect that you can power through many decades of programming knowledge in just a few hours.

u are doing exactly what u had to do to get the task done, and learn from mistakes so u work more effeciently