Ask HN: How can I tell if I am a good developer?

And it's arrogant (in a way) to think the people that hired you are blind fools for seeing potential where there's not. In other words: trust yourself. Bad hires happen but the bad hires are usually not the first to point that out.

>In every company I was good at ... to analyze problems.

>Every company had this one (or more) people who just coded and could put a solution into code super fast. ... I grasp things fast but my code was never as clean, good or delievered fast enough.

That's the point of working in diverse teams. A few teams I have worked on code bases that were clean as a clean room, everything solved by the books but on a high-level flawed, with errors while running in production, hard to maintain, modify and extend.

If you look at typical "startup code" (or "scientific code") you quickly realize that's it's rarely that clean. On the other hand that's where the money is at and also it can be cleaned up afterwards. From my practical experience I can say that super clean code bases are much more static and it takes longer times to change them.

So yeah, if you're good at analyzing stuff that's super useful. Especially if you intend to work at more complex domains. Also I'd suggest to work with Python, I think there a pragmatic approach is more welcomes. (Also interesting, fairly complex stuff is done with Java at some places)

Try to release this tension a bit, stay with the team, adapt, work hard and observe. You have now perspective after only one month. Revalidate it after 3 and then after 6 mo. And don't forget to not stop improving and adjusting.

Your story reminds me a bit of mine. I joined at some point a very skilled, but small team of engineers working on a product from machine vision area. Those chaps were brilliant engineers, many with significant achievements in academic / coding championships. They were truly passionate on what they were doing and were really good at it. And I felt that I was 'just another regular dev' who cannot even compare with most of them, but who also liked coding and the problems domain.

After first month working there I was quite stressed, as was I constantly seeing the gap in my skillset, but I tried hard to manage. After 3 months, I was slowly 'getting there', working on the full stack, but still had the impression of vastly underperforming vs the rest of the team. After 6 months I finally got into the rhythm and started being given more senior and responsible tasks. It took me a while, but it was really worth it.

Although today I am working in another place (and country), but, really, working with that skilled team was one of the most productive and self-improving times in my career (and I still kind of miss these times and the team).

When you are somewhere where you are learning tons and yet you aren't being fired and your needs are being met -- you are in the right place.

I very much like your style - creating a good team spirit and analyzing problems are underappreciated skills in our field of business. These roles should by no means be exclusive to team leaders and analysts because they can make all the difference in difficult projects.

Because you switched stacks, you can truly not yet be compared with the veterans who already have vast experience with your new stack. You have to rely on your other skills to provide value to your team. It is more important for senior developers to understand the domain they are working in, but eventually you will also be expected to catch up in terms of technical knowledge.

By all means, don't quit - you are likely doing better than you think. As long as you continue to do your best and work on improving yourself, it is your employer's job to judge you.