Hi! I hope all is well. I am loving this instance and all the communities so far! As I am a new grad software engineer who is gonna start working in the next month, I was wondering if there are some tips, advice and some nuggets of wisdom you want to pass to this clueless person making this post lmao.
You must log in or register to comment.
Make your code as simple and brainless as possible.
The vast majority of time spent working with code will be debugging or reading other people’s code, so if you write something incredibly clever, you’re just making the next person’s job (who could be you in 6 months) harder.
Remember that, “other people’s code” includes the stuff you wrote 6 months ago.
Look at mister ‘I remember my code for up to 6 months’ here.
Har!
On a serious note, it’s not about remembering the code as much as it is about how much you learn and change over time. If you’re progressing as a programmer, then you’re going to be constantly humbled every time you look at your old code.
I don’t know how many times I’ve opened up a program and thought, “What idiot wrote this shit? Oh…it was me.”. And then you realize that your probably gonna think the same thing about the code you wrote yesterday in another 6 months.
So the least you can do today is to take the time to learn and follow the basics of “clean” coding. That way, your shit code will at least easy (easier, easyish maybe) to follow.
Since we’re serious now, I remember my code all too well, even stuff I’ve written 15 years ago. Specially my thinking process behind the structure of the project.
Throughout the years I learned to always solve everything in the most simple and direct way possible. That way no one should guess what was the intention behind it. And if the code isn’t obvious to the beginner, it gets comments with explanation on why is it necessary.
I had a colleague who knew too much about Perl, and enjoyed the most ridiculous and convoluted shorthands possible. And he was a team lead. It was not fun explaining every time that almost no one else is going to be able to read that, and he pushed it regardless.
To add to this is it’s harder to read code than it is to write so write simple code so that when you come back to it you can understand.
so so true… I would highlight that simple & brainless is almost never short or concise. Put it another way - If just condensed 5 lines of code into one without fundamentally changing the way it works, well just ended up with a single line with a complexity of 5…
and yes, I’m looking at you Scala devs, with 20 functions chained in one row 👀
don’t objectify women. don’t be afraid to ask for help. don’t trust people who think meetings are work.
Just moved to management and your last sentence hurts. I’m in meetings for 25-30 hours a week and I definitely think it’s work. But for a dev I definitely believe in the Maker’s Schedule.
Yeah, anyone who doesn’t consider meetings as work either isn’t in management, or has very bad managers.
Yes. Listen to this episode of SE Radio where they talk about salary negotiation. Salary is a weirdly taboo subject and doesn’t get talked about enough. Your salary is the single largest financial decision you will make in your life. Bigger than houses and retirement because you cannot do those without being paid.
On a more light note, you will experience a lot of impostor syndrome when you begin working. If your college career was anything like mine you learned how to program but not how to use popular build tools and frameworks. There will be a learning curve. Your fellow workers understand this. Try to make friends at work. Just a little small talk here and there. Especially if it is remote work because it is so much more difficult to bond. This will help you feel like you’re not being annoying when asking for help. It is better to ask for help than sit there stuck. Not everything can be figured out on Google lol, like internal tools and processes.
Edit: ALSO keep a log of everything you do to set up your development environment. A lot of places have outdated docs for that or nothing at all. Documenting it as you go will help others onboard after you and also makes a good first impression of taking initiative.
Don’t take too long trying to figure out a challenge by yourself. Ask questions. Unlike in school, you are allowed to ask for help with your work.
Learn how to write unit testable code as soon as possible (SOLID principles). Learn how to write concise and relevant unit tests. If it’s not in your team’s culture to write unit tests, then you go be that guy. It’s good for you and it’s good for the product. Unit tests are one of the few things in the programming community that everybody believes are a good thing.
I couldn’t agree more!
I had a great colleague at my previous job, who was great at reminding folks that we’re there to get things done together and struggling in silence was the opposite of that. If you can’t figure it out after an hour, give someone (anyone!) a holler and get a second opinion.
Tip 1: Assuming you are starting work at a company that has a healthy culture, do not be afraid to ask for help! There’s a lot to learn and it’s going to take time to get up to speed. Don’t freak out because you aren’t slinging PRs like the rest of the team after a week.
However when asking for help, you should open with what you’ve done already to help yourself. It’s important to respect your peer’s time, so trying to optimize for efficiency and help them help you as much as possible.
Part of this is also not spinning your wheels and struggling for so long that they need to spend a ton of time helping digging you out of the hole you dug for yourself.
Tip 2: Next is it’s important to pay it forward. Docs are super outdated and you got more current knowledge from a braindump from a more experienced engineer? UPDATE THE DOCS!
Tip 3: Once you find your footing, and ship some projects and get a feel for things, it’s important to find your voice. If your most Senior engineer on the team proposes something, don’t just follow it blindly. If you see a blind spot in the approach, please raise it! Ask questions!
Truly great senior engineers hate it when the team just rolls over and blindly accepts their proposals/architecture. They want feedback! No one is perfect or sees everything. They want the team’s help to stress test the approach.
Tip 4: Make sure you keep an open dialog about expectations with your manager. Never assume your manager knows how you spend your time every moment of every day. Ensure you give your manager visibility into your “invisible work”.
Examples of invisible work would be taking time to help a new hire. Having conversations with people on another team you depend on or who depends on you to come to consensus on an approach that is beneficial to both teams. Or something like updating documentation or spending time in meetings to review engineering designs, collaborating with product and designers, etc etc etc
Tip 5: Don’t be a dick. Avoid being super defensive and assuming others are out to get you, embarrass you, or generally are operating in bad faith until they prove otherwise.
Tip 6: Respect what came before. You’ll surely come across some seriously jank code, or a ton of tech debt, or poor approaches. Due to business needs of the time, crunch time, lack of resources, etc are often reasons people did what they did. They very likely know certain things are bad. Calling out bad code or architecture isn’t impressing anyone. They know.
When identifying these things, start by asking for context. Come with solutions that are attainable. Calling out things without fresh ideas on how to solve these known problems is not helpful and a waste of everyone’s time. Focus on approaches for how to fit fixing the problems into your team’s resourcing.
Tip 7: Learn to communicate in a way that resonates with your audience. Try to understand their motivations and what matters to them. Saying that something sucks and we should rebuild in your preferred tech is not an argument. What’s the value? How long would it take? What are the trade offs? How does doing this work achieve the businesses’ goals?
Be open to other views and learning. At least until you learn you’re in a bad environment.
Be interested in cause and reason. Document what is not documented and had to ask.
I think there’s too much to development and work to give good, practical, generic advice.
