The lessons he learned at the beginning of his #SoftwareEngineer career are quite similar we've encountered on our path and put as principles for junior #developers.
What are those principles? 🧵
Principle #1: Don't listen to your ego — talk to your team
Stop caring about your thoughts of what other people might think about you. It shouldn't matter to you.
Always talk to your team when you are in trouble, share your thoughts, get answers/help, and continue growing.
Principle #2: Be braver — say (nonsense) aloud
A similar one, but still quite different: if you get an idea or thought - say it aloud during tech meetings, discussions, one on ones and so on.
Doesn't matter how bold it is - don't hold it back. Say, get feedback, and move on.
Principle #3 (unpublished one): Take on responsibilities proactively
This one is another way of looking at Dan's issue when he got comfortable with the problems set at work.
Dan's recommended to start investing some time into non-work coding (open source, side projects, etc)
It's a great choice.
Alternatively, you can start taking on new responsibilities at your work and fix problems, other engineers do seem to ignore:
— Find an old dependency that is bothering devs working on the product and learn what will take to migrate to a newer version.
— See how errors are logged and stored - may be right now your team is relying on basic `console.log`s which does not provide enough information and cannot notify you about emergencies quickly
— Invest some time into learning how to prepare releases, how to rollback in case of an emergency, what CI or other tools your team is using for building products, and deploying them. Check out whether it's possible to speed releases or automate them even more.
Taking on these responsibilities makes you learn new tools, concepts, and technologies.
It teaches you to fix and improve the things that matter, which many engineers often reluctant to do - as this is often not a straightforward #coding or algorithms knowledge exhibition🤷♂️
Your company's business will also benefit from you solving these problems, though it may happen indirectly - through faster releases, quicker bugs reaction, improved developer experience (DX), etc..
While you will expand your knowledge and become a more experienced engineer 🥷
If you interested more, we recommend you to read a full-fledged article explaining these principles: dev.to/bandaworks/pri…
And at the same time, we highly recommend you reading Dan's article as well - it'll help you make your career start even greater 😉
• • •
Missing some Tweet in this thread? You can try to
force a refresh
When #coding something, always approach the problem iteratively.
That means that as #developer you go through roughly 5 stages:
1. Make a straightforward solution 2. Cover edge cases 3. Improve the performance 4. Improve the design 5. Reduce complexity
🧵👇
1. Make a straightforward solution
It's the basis of your work: it's rough, potentially inefficient, and may not work in the edge cases.
Copy/paste here instead of creating complex reusable components.
Here's the goal to create something that actually works, but not perfect.
As a junior engineer, you should be able to come up with at least one such solution, after thinking about the problem for a while, researching, and discussing with more experienced engineers.
If you still can't, the problem requires more expertise than you currently have.
- Why are you doing #frontend projects?
- To practice #webdev
- Okay, why do you practice web dev?
- To land a dev position in a #tech company or startup
- Why do you need to land a dev position?
- I see. I want to secure my family's future.
🧵to remind you of the reasons:
One day, everyone who is going through the path of becoming #developer, experience this unsureness.
We may feel afraid of a lot of requirements out there to get a job.
We may have trouble in our personal life.
Honestly, there may be a lot of reasons for us to experience the decline.
There are many recommendations people give in that case:
- Take a break for a few days
- Change the location: e.g. get from home to a coffee shop (like Starbucks) and practice there
- Find a coding partner