How are new hire software programmers expected to be?
If you've just got a programmer job from your dream company, congratulation! There is nothing as blissful as that. Your programming skill got you to layers of interviews and you made it to the offer stage, of course you are proud of it. However, programming in a corporate environment is not like solo coding, individual programming skill won't get you a promotion. Knowing what your company expects from you and leaning towards them will pretty ensure a smoother career for you to display your coding talent further.
1. You are not expected to shine on your very first day
No matter what position you were hired to be, your very first day will be getting familiar with the existing system, the workflow, and your colleagues. You are expected to ask a lot of questions, make some mistakes, and learn them on the way. Don't be so eager to point out any flaws in the current system, criticize them (unless they are freaking critical that would corrupt the whole business), or immediately interrupt your mentor if they are talking about something you have known already. Doing so will bewilder your mentor, your colleagues, and inevitably they will start thinking of you as a newcomer asshole, which is not good if you are going to stick with them for a while. Also, you are not expected to try hard on your first day. First, getting used to the system, learning about the workflow, the working culture, your colleagues' working habits, and adapt to them at your own pace. Doing great work on your first day will only raise the premature expectation on you, keep you busy to live up to it, and end up making you burnt out later. Therefore, knowing and adjusting yourself to be suitable for a long run would be a wiser and smarter choice. Lower your standard, and heighten it later.
2. To learn, you have to unlearn
Guess why companies prefer freshers to mid-careers? Freshers don't need time to unlearn what they were stuffed in the previous workplace! They will quickly get used to the working environment and be able to provide the result promptly and efficiently. Every workplace has its own internal rules and workflows, the quicker you familiarize yourself with them, the faster you will thrive. Even though the workflow of a business that worth billion dollars seems superior to the workflow of a venture, it doesn't necessarily mean that venture must change their workflow at once. Many workflows struggle in large corporations but shine in ventures. Or the reason that a venture hasn't switched their workflow to something better is that they have a particular reason which is holding them back from improving. Even though your former company has a superb workflow in contrast to your current company, instead of criticizing, try to understand it. There always has multiple ways to solve a problem.
This also applies if you are a graduate fresher. Principles, laws, design patterns you have learned in your university may only be partly usable in the corporate environment. Profit, economy, and efficiency are the most prioritized matters there. Everything you have learned in the university may be bent to fit into the bigger picture. Differing from the standard doesn't mean wrong, the only thing that matters is the outcome. By accepting it as part of your job and getting used to it, you will become more flexible, improve your problem-solving skill, learn new ideas and broaden your career path.
3. Learn to cope with the existing system
Before improving a part that was already up and running, look for every place that the change might affect. If the effect is too huge, or the improvement dramatically raises the labor cost, let's overlook it for now. Every programmer encountered at least once in their career life a spaghetti code, a bad software design, or anything that went against the Bible of Good software programming. I know a system serving about 200k users at the moment that doesn't employ 1-n relation in its database design. Instead, the table has to be altered by adding a column manually each time the related data is increased. If the data is increased by about 100 records, there will be 100 more columns added to the table! Sounds catastrophic right? Of course, if columns are frequently added that way, definitely the system design must be reconsidered. But how about only one or two columns would be added in a decade? In this case, let's put up with it. Even if you try to change the database to the correct design standard, there is a good chance it will affect other existing parts that you completely have no ideas why they were related, cause mountains of regression bugs, trouble thousands of users, and may eventually fail the whole system! And you will meet more bad designs as your career advances. OOP bad design, bad code, repetitive code, fabulously nested if-else structure... anything you can name. If those are in an in-house project and it hasn't been released yet, improvements are much more negotiable. However, when the product was launched and started serving users, current user state and system condition must always be kept in mind when introducing new improvements. More often than not, your team members will deny any changes that produce mediocre visible enhancements but could induce regression bugs and potential system failure. So, if you come across a duplicate code, a terrible OOP design or something alike in your company's commercial products, or your client's running system, discuss with the people in charge before making any improvements. If you have to make some changes to the existing system, the way that complies with the design standard may not be the best. Choose a way that the number of parts you have to change accordingly is the smallest.
4. Conclusion
Hopefully, my experience could be somewhat useful to you, even if you are a sparkling graduate fresher with an A+ grade or you are a seasoned developer who has just started the first day in the new office. In the workplace, you will be inevitably challenged to embrace more than just pure programming skill. Do not limit yourself to what you have learned, be open-minded, selectively adapt yourself to what corporation expects and you should be fine and continue to thrive in your programming career.