I started working 2 months ago in my first job as a programmer in a medium-sized company, before I had only done personal projects for 4 years. I live in a place where there is little work of this and much less that they hire you without regulated studies as is my case. So I can't afford to lose it until I gain some experience.
They are assigning me quite delicate projects: making the cart change its price dynamically taking into account payment methods, and so on. At the same time they are wanting me to refactor how the order lines are processed to generate orders to suppliers or take it out of the warehouse, etc.
Some points that I find worrying added to the above:
- The way they have to upload to production is by taking the modified files in your project manually looking at the git log and uploading them manually with Filezilla renaming the original file with .old
- My supervisors don't check my code
- The project is too big to understand and is mainly written to barely hold
- I have to learn the logic of the company mostly on the fly because they give me vague explanations even when I ask for it
- The code is not documented
I would like to improve as much as possible as a programmer and do things with the least possible errors to endure as long as possible, but it is costing me a little more than I thought. I understand that I cannot demand much more of myself because it is a complicated project but I am afraid that my supervisors do not see it that way because of how they talk to me when I break something.
They have 2 years of programming experience and I suppose even less as supervisors / managers.
I wanted to ask you for advice on how to manage my situation and do my job as well as possible, I would greatly appreciate any advice or comments.
2/ Have a reproducible process (could be manual) to test that the change you made did not break things.
3/ Spend time on things where you can produce results quickly. Bail on things that are taking too long.
4/ Take walks and think about what is going on. Are you solving the right problem? Is there a different approach? Should you switch jobs?
I mean if you’re beginner and you don’t have anybody to give you deep feedback - only by accident or extreme talent you can migrate it to good architecture and learn valuable lessons along the way.
In general: career success is less about what you know and more about who you can collaborate and communicate well with.
Not every code is pretty so it should make for an interesting learning curve.
Walk through every line of code and create your own documentation using something like this - https://www.writethedocs.org/guide/writing/beginners-guide-t...
Break down the problem into sub-problems. YOU CAN use user stories if possible to understand the business logic.
Talk to your manager and set expectations. It seems they have given you a task that might be more than your currently knowledge set. It could a learning opportunity or a roaring disaster. Either way make sure you tell them what you can do right now and what may take you longer to do.
Write lot of unit green test cases , keep green bar BEFORE going for refactoring or anything.
- https://news.ycombinator.com/item?id=19924100 (understanding codebases, etc.)
- https://news.ycombinator.com/item?id=26591067 (testing pipelines, scaffolding, issue templates)
- https://news.ycombinator.com/item?id=22873103 (making the most out of meetings, leveraging your presence)
- https://news.ycombinator.com/item?id=22827841 (product development)
- https://news.ycombinator.com/item?id=20356222 (giving a damn)
- https://news.ycombinator.com/item?id=25008223 (If I disappear, what will happen)
- https://news.ycombinator.com/item?id=24972611 (about consulting and clients, but you can abstract that as "stakeholders", and understanding the problem your "client", who can be your manager, has.)
- https://news.ycombinator.com/item?id=24209518 (on taking notes. When you're told something, or receive a remark, make sure to make a note and learn from it whether it's a mistake, or a colleague showing you something useful, or a task you must accomplish.. don't be told things twice or worse. Be on the ball and reliable).
- https://news.ycombinator.com/item?id=24503365 (product, architecture, and impact on the team)
- https://news.ycombinator.com/item?id=22860716 (onboarding new hires to a codebase, what if it were you, improve code)
- https://news.ycombinator.com/item?id=22710623 (being efficient learning from video, hacks. Subsequent reply: https://news.ycombinator.com/item?id=22723586)
- https://news.ycombinator.com/item?id=21598632 (communication with the team, and subsequent reply: https://news.ycombinator.com/item?id=21614372)
- https://news.ycombinator.com/item?id=21427886 (template for taking minutes of meetings to dispatch to the team. Notes are in GitHub/GitLab so the team can access them, especially if they haven't attended).
- https://news.ycombinator.com/item?id=24177646 (communication, alignment)
- https://news.ycombinator.com/item?id=21808439 (useful things for the team and product that add leverage)
- https://news.ycombinator.com/item?id=20323660 (more meeting notes. Reply to a person who had trouble talking in corporate meetings)
- https://news.ycombinator.com/item?id=22715971 (management involvement as a spectrum)
- https://news.ycombinator.com/item?id=25922120 (researching topics)
- https://news.ycombinator.com/item?id=26147502 (keeping up with a firehose of information)
- https://news.ycombinator.com/item?id=26123017 (fractal communication: communication that can penetrate several layers of management and be relevant to people with different profiles and skillsets)
- https://news.ycombinator.com/item?id=26179539 (remote work, use existing tooling and build our own. Jitsi videos, record everything, give access to everyone so they can reference them and go back to them, meetings once a week or two weeks to align)