How do I know I'm not unknowingly messing up my software apprenticeship?

The first sign that you're not is the fact that you're concerned that you might be.

Give me someone who's a little insecure over a know-it-all any day. It means you're going to ask questions, double check things, ask for opinions, and look for ways to improve.

Another sign is that you're not getting feedback. I tend to not give feedback if something works well. If you're really concerned approach someone. My guess is that they're happy enough with your work and level of competence to leave you be. You know, the old "If it isn't broke, don't fix it".

The best way to approach this is to ask a senior person to sit with you for a while, explain your feelings and tell them that even if your work is up to par, you'd like to review your code and see what he thinks you're doing well, and where you could improve.

Take the initiative and your reputation will go up in the company. Asking for help has a psychological effect on the person you ask. They put it in their mind that you are worth helping. This is a good way to set up a win-win.

This sounds to me like classic Impostor Syndrome, and trust me, every developer gets it from time to time. I do, and I've been coding professionally for seven years now. And I often have days even now where I think someone's going to tap me on the shoulder and go "just what were you thinking sunshine?"

It is good to take stock of your abilities, but can I encourage you not to compare yourself to others. It sounds like you're surrounded by experienced developers, so bear in mind that they have a head start.

It sounds like you're trusted to work on production data, and trust me when I say that they wouldn't let you anywhere near that if they didn't trust in your abilities.

Now with that being said, you feel like you're not a real developer, and that what you deliver is complete garbage, I would counter that the fact that you're working on a live system shows that what you're doing isn't complete garbage.

BUT it is good to take stock of your abilities from time to time, as it can reveal weaknesses which you can then address.

The fact you're trying to learn good practice is a very good thing and I can recommend a couple of books for you to that end. The first is Clean Code, this goes in to the principles of writing good and clean code. The second book is The Pragmatic Programmer. This is a book on taking your craft seriously. And it is full of excellent advice. The third and final book is The Clean Coder, which is by the same author of Clean Code, and it's a code of ethics of sorts for someone who's looking to call themselves a professional developer.

Trust me when I tell you that a lot of programmers aren't backwards in coming forwards when your code is rubbish. I've been on the receiving end of a code review more than once.

And remember you're an apprentice, so they should be training you. If you use Github or Bitbucket within your company, you can use pull requests as a way of doing code review for example.

Just a few thoughts, which ended up being quite long...apologies

Nobody here does code review, the other developers say they trust me to not mess up production data with silly mistakes.

Other answers have suggested getting feedback from coworkers/supervisers. This is the best solution, but in case you meet unwillingness or pushback you can look for other ways to have people review you code.

If you have any personal programming projects (don't post work code), you can post them on http://codereview.stackexchange.com/ for others to look over. The tour page for that site says:

Ask about...

The quality of your working code with regards to:

• Best practices and design pattern usage
• Security issues
• Performance
• Correctness in unanticipated cases

You will get people pointing out ways to improve your code, but keep in mind that all code can be improved. If no one points out glaring mistakes or design patterns you have never heard of, I would say you are doing well and your code is up to par.

the people in the other departments are just too polite to say it.

I'm horrible at this and the people in my company are just too polite to tell me.

I don't think the issue is your ability to code so much as your inability to judge other people. :) In my experience, people being too polite is not only an exception but it's a sign of a bad employee, at least in that regard.

Think about it like this: If someone thinks you're screwing up and doesn't take steps to let you know about it, they are doing harm to the company itself. If these people take their jobs seriously than you have to take them at their word.

You saying they're too polite to tell you that you're horrible is the same as saying that they're willing to hurt the company (and possibly their own work) just to save your feelings.

Unless you're working for your mom, I highly doubt that's the case.

Nobody here does code review, the other developers say they trust me to not mess up production data with silly mistakes.

Everything you say seems to lead me to the suspicion that there's nothing wrong about you, there's something really wrong with the company. A company that doesn't do any sort of code-review or, at least, some unit-testing/code-coverage (let alone automatic deployment), is not a company worth working for. Something will blow up very soon. Start polishing your CV and run away to a more decent company.

I had a somewhat similar experience working in a position where part of the job description was explicitely "to learn how to do the job" - yet my supervisor only made time for discussing progress every one or two months. That's far too infrequent to pick up the daily business or get real guidance from them. I also had my doubts about my own competence (read up on impostor syndrome if you haven't done so already).

What helped for me was:

• Finding (other) mentors. Badgering colleagues until one in particular took pity and discussed my work with me, suggested improvements, showed me the tricks of the trade, and also told me about the realities (and not only the idealised version) of the job.* Try your best to find this helpful person in your company. Who knows, if you ask, maybe your Ausbilder finally decides to do their job! (But obviously don't ask in these words...) If you can't find anybody like that, consider skipping to bullet point #4.

• Going to workshops and conferences and generally meeting other people in the same situation (in your case Berufsschule?), discussing work with them, networking, and finding out that doubting your work is not that unusual (and sometimes helpful, to a degree). Maybe find a workshop/course about software quality and ask your supervisor to send you there; offer to present what you've learned for your colleagues (they sure could use it!). Also has the plus of "showing initiative".

• Teaching. If there are people even more junior than you (like the newer apprentices), try giving them the introduction and help you missed when you started. You improve your grasp on a subject if you try to explain it to others. If there is no one more junior, buy a rubber duck ;-)

• Ultimately: leaving that company and finding a place more concerned with the development of their employees and the quality of their product. I don't know how much you can change about this company as a grunt. Maybe they would welcome efforts to establish some software quality process, that'd be a good sign. If they don't, you'll probably have a much easier time finding another company that fits you than changing their culture. Whether that comes before or after your exams is something you'll have to figure out (sometimes you just have to stick it out and sometimes ending it quickly means less pain).

* Regarding your situation: You would not believe the amount of shitty software in production around the world (I had to deploy some of it myself ;-)), so if people don't turn up at your desk shouting you aren't among the worst coders.

Also: a whole company/department of software developers being too polite to tell the grunt about his/her mistakes sounds fantastically unlikely. There's always one who will tell you about your shortcomings in minute detail. Don't worry about them thinking little of you, worry about your bugs which they haven't spotted because they have no idea about software quality.

Request code review and feedback from your direct supervisor. Let them know that you are unsure if you are making progress in your field due to lack of feedback. With respect to clients, the vast majority of the time "if it works it works" and you won't get any feedback unless it's broken.

Be aware of imposter syndrome. Many people are baffled at the trust that others show in them. It's entirely possible that your thorough nature leads you to produce at a higher level than your peers and that you are meeting all objectives. Without direct specific feedback you just can't know.

I'm not going to focus on the personal and interpersonal aspect of the question, as they're covered well enough in other answers.

I instead want to focus on the technical aspect.

Testing

You said you're writing unit tests. Do you try to have full test coverage? Do you write integration and end-to-end tests?
Don't forget that a good testing suite has all three aspects of testing, and having everything tested will make you feel more secure.
Dropping testing in favor of delivering more is a temptation anyone has, sooner or later, and it's far too easy if you're left by yourself and don't have testing standards. Force yourself to test, and never consider it a waste of time.

Code metrics

Try using a code metrics tool (giving you a specific tool is impossibile since you don't specify the language you're using), and conform to industry standards when it comes to writing function names, variable names, etc. (nobody wants to see hungarian notation in their java code).
Obviously, you should first of all keep your code style coherent with the one used at your company. Try to read the other devs' code and learn how they write.

Deployment system and Bug Tracking

Since you are just 5 developers inside a bigger company, you probably also lack deploy and bug tracking tools.
Trying to at least standardize (if not completely automate) the way you deploy the product will reduce the risk you give someone an outdated file or library, and having a formal bug tracking system will help people tell you if your product has issues or bugs.

Having everything automatically checked and tracked will surely improve your confidence, and will help you deliver a great (or at least good enough) product.

I think all software end-up being crap eventually. So it is an iterative process to refactor bad places when changes are needed. There are good ideas in the other answers but I think that you recognize crap would allow you to next time do it better and better. You can take trainings, read books, blogs whatever. Take everything is a grain of salt. Think and try how things work when applied.

For example microservices are awesome but for a 2 page web app, using microservices would be a total overkill and time waste. There's no single approach to produce best results. Another example would be SQL vs NoSQL. You use one on the other depending on use case, scale, etc.

The sole fact that you recognize software crap makes me think you do at least better than average. I've seen lots of people that do not recognize crap in code and that produces real crap beyond repair.

It sounds to me like you are doing just fine. Having test automation already puts you ahead of much of the competition. Having tests which tell you that you did something wrong is the ideal, of course; if this happens rarely, it sounds like maybe you should put more effort into the tests. But again, having tests to prevent you from breaking existing functionality is an excellent metric all by itself. If you are confident that you can refactor your code and your tests will catch most (I won't say "any") mistakes, you are probably already in the top 10% in terms of discipline and professionalism.

Now, when it comes to your apprenticeship, I can't help but think that you are not getting what you came there for. If your employer is not helping you develop your skills, you should get in touch with your school and see if they can offer you another place to work, or a way to improve the experience in your current position.

Similarly, if your current position is not one where you get to practice version control, code reviews, pair programming, extreme programming, agile programming etc. then maybe you should contact your study supervisor and outline what hopes and expectations from your apprenticeship you feel are not currently fulfilled.

As humans, we are perhaps too good at adapting to the status quo. I'm a bit hesitant to suggest that you rock the boat, but the tone of your question suggests that you are not currently happy with your situation, and are looking for something to help you find a way out.

At the other end of the spectrum, many of us are impatient. Think about what your school offers, where on the professional spectrum you expect your co-students and yourself to end up, and whether the current program is the one you actually want to be in. Perhaps the school and the apprenticeship are not on the level where you want to be professionally and academically? In your case, perhaps consider following this path to its end but then attempt to get a higher degree?

A decent apprenticeship should be giving you this sort of feedback all the time. If anything it should tend towards being overly critical as you are there to learn not feel all warm and fuzzy.

If you're not getting proper feedback the first thing to do is to ask for it. An apprenticeship shouldn't just be cheap labour nor should it be bureaucratic box ticking going thorough the motions of work experience, it requires some investment of time and effort on both sides.

So you may need to be a bit more proactive and seek out the feedback and advice that you need. Don't be afraid to approach people and ask them for feedback, advice or just to find out about what they are doing. You may be surprised to find that people are actually pretty keen to help you, especially if they are any good at their job.

Also approach people and as if they need any help with their work, this a) is a generally good attitude which should get noticed and b) may give you the sort of challenges that you need to learn.

However don't be too surprised if you end up with somewhat boring and repetitive work.

It may also be that this work placement is not a good fit for you so it is well worth taking your concerns to your academic supervisor/tutor.

The other answers mostly suggests talking to supervisors/peers/feedback about your doubts which is a good idea. But that may not shake the feeling "they're just being nice" unless you figure out the specifics.

There's this approach to deal with self-doubt - computer people have those little meritocratic competitions of one-upmanship - to establish more or less objective merit in different categories.

Let's have a small problem at hand and bunch of people try to have a go at it (and I don't mean fizzbuzz, I mean something real). The point is gathering discrete points feedback about your solution. Is it a quick and dirty, yet clever hack? Then you're a clever hacker. Is the code fast but barely readable? Then you're a whiz, possibly with baggage in other areas. Is the result subpar, but you deliver really fast? Then you're a speedy code monkey. There are many much more such attributes.

The "good" or "bad" coder is aggregate measure of how you're useful in general scenario. But in context of your company, it's not black and white, despite people constantly trying to get aggregate answer (on SO, upvotes, from your supervisor "yea/nay"). You need to ask about specific breakdown of your strong and weak points, and where it may cause problems and where it does not matter.

Because ultimately, the answer depends what the company is looking for, they don't care about attributes they have no use for. To give examples, do they need speedy monkey? Do they even need QA? Or are they ok with flexible hacks dealing with the ad-hoc, rather than being systematic? Do they need fast code because hardware/responsivity is a criterion? The list goes on...

While RichardU's answer is fine with me (i.e., nothing seems to be wrong with you), I would still suggest that you try to change something.

Your company is quite typical; it does very laissez-faire development. It's not a problem now, but if you stay there for a few more years, you may end up getting so used to it, that it could be problematic for you to catch up. If you will be happy like this until the end of your life (who knows), then fine. But if there should arise the day where you are fed up with this kind of work (for example, if you want to become more involved with larger projects, maybe as a lead developer etc.), it may just be a little too late.

So, in your situation, I would slowly try to change something, step by step. Try to introduce some semblance of a more professional development process (at least marginal amounts of peer review - think "truck factor"). If you just cannot achieve that, then put out your feelers for another job. I am not suggesting that you should put yourself under pressure; just have an open mind.

I would definitely not suggest to lean back, pat yourself on the back, tell yourself that you have "impostor syndrome" and keep hacking like this forever!