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

Question

I'm currently in the second year of my apprenticeship as a software developer in Germany.

My day-to-day work consists of getting tasks, doing them and then handing them off to the customer (other departments at my workplace, no external customers). Basically, for all intents and purposes, my direct superiors (the other software developers) don't really interact with me unless they have tasks to delegate.

I started learning coding about 1,5 years ago, so I'm very sure my programming style and ability are nothing really to write home about. Besides occasional questions about our specific code base in the company, most/all of what I know comes from Stack Overflow and online tutorials.

I can't shake the feeling that I'm not a real developer, that most of what I deliver is complete garbage and the people in the other departments are just too polite to say it. Nobody here does code review, the other developers say they trust me not to mess up production data with silly mistakes. (I do my own deploying, we don't really have a process here, it's five developers, including me, in a bigger company).

My classmates in vocational school always tell me about how they're heavily supervised, and how they have people scrutinizing everything they write. It seems at my job that's not an option.

I try to find good coding practices and do unit testing, but I have no clue if it works. If people find outward function issues with what I produce, the people from the other departments come to me directly.

How do I get a grip on where I am in terms of ability and where I need to improve? I can't shake the feeling that I'm horrible at this and the people in my company are just too polite to tell me.

Answer 1

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.

Answer 2

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:

• Clean Code goes in to the principles of writing good and clean code.
• The Pragmatic Programmer is a book on taking your craft seriously, and is full of excellent advice.
• The Clean Coder 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

Answer 3

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 https://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.

Answer 4

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.

Answer 5

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.

Answer 6

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.

Answer 7

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.

Answer 8

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.

Answer 9

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.

Answer 10

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?

Answer 11

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.

Answer 12

I was in that situation about ten years ago, when I started. I know how you feel. By now I am on the other side and have trained a couple of Azubis (apprentices) full time until they were done, and also had some that get rotated through departments on a three month basis.

If your Ausbilder (the guy responsible for the apprentices) is not the right kind of technical person, treat him as your people manager. He is your boss, yes. But he can delegate. Typically individual lessons (Ausbildungseinheiten) that are based on the targets (Groblernziele) set in the document that describes the apprenticeship (Ausbildungsrahmenplan, Ausbildungsordnung) are done by individual people, not by the Ausbilder. In IT, that's hard. Especially because in smaller companies, people are busy.

Make sure the Ausbilder is actively delegating. Ask him to assign a dev who is responsible for you. Ask the devs directly for someone who would like to mentor you more.

If you are productive, and you get stuff done, and your stuff works, that's a great start. If no-one complains, that a good sign. Germans like complaining. If you would suck, they would tell you. But if you get stuff done on time, or faster, and if you have time to sit around and earn internet points on Stack Exchange and still get everything done on time, you are doing a lot of things right. (Maybe not the hanging out here part, you could always find more stuff to do :)).

If there are different Azubis or other people your age, talk to them about this. Even if they are more sales-oriented or if they is someone training to be a Buerokauffrau. They might experience the same thing. They relate. Talk to them. Together stuff is easier.

At school, talk to your friends. Ask them about their Ausbilder. Find one that has a very good relationship with theirs. Maybe their Ausbilder is only a few years older. Try to meet them. If their company culture encourages barbecues, going for drinks after work or stuff like that, ask your friend to be taken along. Then discuss your situation with the cool Ausbilder. They will listen, they will be sympathetic. They will probably offer advice, or offer to look at your code and tell you what they thing. I would offer that, anyway.

Contributing to Open Source has been mentioned, and you do that, here. But your technology stack is not ideal for OSS. That makes it harder to do that. But there might still be meetups for some of the technologies that you deal with at work. If you're in Berlin, Hamburg, Frankfurt or Munich, there will be some. Go there. Don't be afraid to talk to strangers. The people that go to those events are interested in technology, but also in meeting people. They will see you as a curious human being who wants to learn and not as a kid that doesn't know stuff yet.

I looked at your SO profile. You've been around there for a little bit over a year. You collected over 5000 internet points. You have a tag badge in C. You contribute to an automated system that helps keep the entire plattform spam-free. Your posts are concise, clearly structured, technically sound (as far as I can tell) and are usually well-received. Your command of written English is impressive for the average Azubi. Out of over 250 questions, only two have a negative score and you have enough integrity not to delete them. And I bet you probably are one of the guys helping the weak students at school, and maybe you are either Klassensprecher if that exists, or you're part of the Schülervertretung in school. I wish I had more Azubis that curious, motivated and nerdy. Keep up the good work. :)

Answer 13

I am a senior software developer with 12 years of experience. I did not study at a university and I do not have a computer science degree. I have worked hard to become good, and to develop and maintain a high level of professionalism.

You have to take responsibility yourself for becoming a professional, and for your own professional development. Ideally a company can assist with that, but you are still the one responsible for it.

There are many things you can do to develop professionalism:

• Learn professional attitudes and habits.
  • Understand that criticism of work is not personal criticism. I learned this on my first job. While it's certainly not a universal attitude, it's immensely helpful when you can criticize an implementation without criticizing the person who did it.
  • Always have good reasons for making a specific choice, and communicate those reasons. Understand that there are trade-offs in every choice, and try to understand the specific trade-offs in each case.
  • Understand that there are things that you don't know that you don't know. This is why it's good to ask questions if you don't understand why a specific choice was made.
  • Evaluate each solution to see if it solves the actual problem.
  • Learn to be a problem solver rather than a code writer.
• Join professional organizations such as the Association of Computing Machinery and strive to follow both their Software Engineering Code of Ethics, and the general ACM Code of Ethics and Professional Conduct.
• Study programming books like The Pragmatic Programmer, Code Complete, Clean Code, Working Effectively With Legacy Code, Refactoring and Peopleware.
  • The Pragmatic Programmer especially shows you some of the basic things that a good developer should be doing, and why. If you have no mentor, then this book is a very good start towards mentoring yourself. It is episodic, and you can jump around in to book.
  • Code Complete is a more serious treatise, but covers much of the same ground in more depth with research to back up the conclusions.
  • Peopleware is the best book about programmer management that I have ever read. It shows that your work environment matters a great deal, and it backs up it's conclusions with empirical evidence. It shows you how you can structure your work space and working habits to be more effective.
  • Working Effectively With Legacy Code and Refactoring are two of the most important books you can read because it is estimated that 80% of a codebase's lifetime is spent in maintenance mode. It is also a common aphorism that programmers spend more time reading code than writing code. This is also why Clean Code is important, because easy-to-read code is easy to modify.
• Do free online courses.
  • Learning How To Learn teaches you how to learn, but also how to solve problems and think creatively.
  • Agile Software Development is the greatest summary, discussion and evaluation of Agile as a methodology that I have ever encountered.
• Participate in online code contests like HackerRank, CodeChef, and Project Euler, and when I solve the problems, I look at other people's solutions to compare techniques and learn from their code.
• Make learning plans and develop your skills.
• Switch on all code warnings and treating them as errors.
• Use linters that warn about bad code practices.

You mention your team is only five strong. I too work on a team with five developers, but after discussing our process as a team we decided to adopt the GitFlow methodology of version control. This means that every change has to be reviewed by someone else before it is merged back into the dev branch.

It is hard to express how much I have learned and benefited from reviewing code, and having my code reviewed by other people:

• Every person has cognitive blind-spots that are only revealed when someone else looks at the same code and asks questions about it.
• Having someone else's perspective has taught me a lot about my code.
• Having to explain your code to someone else during a review activates Rubber Duck Debugging.
• Looking critically at someone else's code trains you to look critically at your own code also.
• A good checklist of things to keep in mind during a code review is also very valuable when creating your own code.
• I review my own code when I commit to source control, looking at each change and explaining to myself it's necessity and purpose.

I would strongly encourage you to learn about the benefits of code reviewing, and then asking your employer to consider implementing code reviews. You can also ask more senior developers to do code reviews for you individually.

Answer 14

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

Answer 15

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!