5 ms·
Ask HN: How a junior can handle a big bad coded project
Hi, I think a bit of context is needed to understand my concern.
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.
- slater 5y ago"affront extend"?
- bouldersharp 5y agoHow should I name it?
- nightfly 5y agoI'd start looking for a new job and move on ASAP. I doubt you're going to learn very much in this situation, and their workflows just sound broken.
- bouldersharp 5y agoThank you for your advice. I can probably find another job. Meanwhile I have to see how to maintain this one.
- aristofun 5y agoIt sounds like there’s not much to learn except how to survive shitty project. 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.
- bouldersharp 5y agoThanks for the advice, then I'll keep doing what I know
- aristofun 5y agoGood judgments come from bad judgments, you know. Wish you best of luck
- asimjalis 5y ago1/ Work backwards from results. Start with an outcome that you want and then figure out what minimal change in the code will produce that outcome. 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?
- chousuke 5y agoI'd like to add to point 1 a plea not to do the thing where people don't understand existing code so they copy it, partially modify the logic and then add branching to choose the correct version. It's fine in moderation to do this, but it increases your maintenance burden faster than it solves issues if you don't ever refactor.
- Jugurtha 5y agoRecycling some replies. More context on https://news.ycombinator.com/item?id=26182988 https://news.ycombinator.com/item?id=26182988: - https://news.ycombinator.com/item?id=19924100 https://news.ycombinator.com/item?id=19924100 (understanding codebases, etc.) - https://news.ycombinator.com/item?id=26591067 https://news.ycombinator.com/item?id=26591067 (testing pipelines, scaffolding, issue templates) - https://news.ycombinator.com/item?id=22873103 https://news.ycombinator.com/item?id=22873103 (making the most out of meetings, leveraging your presence) - https://news.ycombinator.com/item?id=22827841 https://news.ycombinator.com/item?id=22827841 (product development) - https://news.ycombinator.com/item?id=20356222 https://news.ycombinator.com/item?id=20356222 (giving a damn) - https://news.ycombinator.com/item?id=25008223 https://news.ycombinator.com/item?id=25008223 (If I disappear, what will happen) - https://news.ycombinator.com/item?id=24972611 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 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 https://news.ycombinator.com/item?id=24503365 (product, architecture, and impact on the team) - https://news.ycombinator.com/item?id=22860716 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 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=22723586) - https://news.ycombinator.com/item?id=21598632 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=21614372) - https://news.ycombinator.com/item?id=21427886 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 https://news.ycombinator.com/item?id=24177646 (communication, alignment) - https://news.ycombinator.com/item?id=21808439 https://news.ycombinator.com/item?id=21808439 (useful things for the team and product that add leverage) - https://news.ycombinator.com/item?id=20323660 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 https://news.ycombinator.com/item?id=22715971 (management involvement as a spectrum) - https://news.ycombinator.com/item?id=25922120 https://news.ycombinator.com/item?id=25922120 (researching topics) - https://news.ycombinator.com/item?id=26147502 https://news.ycombinator.com/item?id=26147502 (keeping up with a firehose of information) - https://news.ycombinator.com/item?id=26123017 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 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)
- edimaudo 5y agoDefinitely a quagmire but there are some things you can do. Some helpful tips 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-to-docs/ 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.
- mbrodersen 5y agoRead the book: “How to work with legacy code”. It tells you everything you need to know.
- afarrell 5y agoBuild relationships with other engineers so you can ask high-clarity questions and get high-clarity answers. In general: career success is less about what you know and more about who you can collaborate and communicate well with.
- ElectricMind 5y agoMaybe you know this but just to reiterate. Write lot of unit green test cases , keep green bar BEFORE going for refactoring or anything.