Always tell junior devs the same.

You'r not going to become the senior dev or architect you have in your grand vision by sitting around this company fulfilling mundane tickets.

Start thinking through new ideas, possibilities, software that you think could really help a specific niche Or pick a model that already exists. The ideas prior existence doesn't matter but having a new idea that has potential has always inspired me to keep pursuing it.

Break out lucid charts, learn how to map out your domain objects and their relationships. Build out a service map of how you want things to work together. You dont have to know how context boundaries or demilitarized zones work or any that technical jargon. At the end of the day those concepts <should> develop organically and then the jargon will come to you like "oh thats the term for this". Some people learn better from knowing and then implementing. I usually come to it organically then learn about it later. Thats the point of this though. Read up on it, understand enough to map it out and then start building them out.

Use a language you want to be proficient in but are not. Use a framework you want to understand but do not. If theres an auth protocol in high demand that meets your needs but you do not understand, run with it. You'r proficient with mysql; mongo would also be a good fit for the business needs but you've never used it. Perfect, use mongo then.

Find avenues of improvement down the line. Maybe the simple records resource server would be a good candidate for GraphQL. Pull in a pub/sub to increase service communication/aggregation, learn websockets to maintain a vital client interface. If you dont know what the fuck im talking about, perfect! Jump in there. Start small, build up, tinker.

You'll meet soul sucking blockers all along the way and thats the biggest thing that separates seniors from juniors is having worked through these issues before, time and time again. Embrace failure, embrace change, maintain initiative because you can be another miserable dev that keeps the cogs turning making a decent 50k salary or you can be a positive catalysis.

  • 5
    Wholesome rant, favorited! :)
  • 6
    A few additional points:

    - Don't do this on company time. It's not a morality thing, it's a self-preservation thing; usually your employer legally owns any work you do on their equipment (including a loaner laptop you take home with you). Don't fall into that trap.

    - Do this on your own time, with your own motivation, for your own projects. Don't do this at work - your employer doesn't pay you to draw outside the lines (unless that's specifically in your contract and you're being compensated for it, but if you're a junior that's usually not the case).
  • 3
    @junon That is really highly situational. There are plenty of cases where bringing out an idea of a current problem is a valid way to spend time. As a junior dev you are hired as a problem solver. It can probably not come at the cost of great ticket velocity unless they assign you to it. But even that really depends on the company, You can always just ask. That is for job related innovation. If you what to develop a product and for example have your employer be your client definitely have a record of what you do and make sure everything is in private time and check your contract first!

    Because on the other end of the spectrum sucky companies have contacts that own you as long as you are on their payroll. Even discoveries/product development outside the office are legally intellectual property of the company.
  • 2
    See for me I want to take my time to learn a lot before I become a senior dev so I’m not too worried about that, but I’m more likely to not bring up ideas because I feel like I don’t have great ideas than be the person bringing them up, and in general I’m afraid anything I code won’t be good enough and I’ll be that one annoying person always asking “hey can you look at this” or “can I get some help or just talk to figure out a solution” and if I try anything new while at a job instead of on my own I’ll drown and fail and get fired or sumn.

    I don’t think I’m a bad dev at all, I’ve done stuff I’m pretty proud of and I love programming with all my heart but I just over think and beat myself up a lot and idk how to reassure myself about it.
  • 2
    @Bubbles I think the confidence is just another part of the journey to becoming a senior dev. I personally consider myself near that threshold between others considering me a senior dev in my org but my confidence and ability to lead is what is holding me back. I was listening to a gong call the other day from a dev meeting. I spoke up to discuss cyclomatic complexity being measured as a KPI objective. Not thats not an easy subject to discuss and wasnt considered by any of the seniors i work with who have 2-3x the experience so I applaud myself for taking the initiative. BUT when hearing myself speak, I was not confident in my approach. I sounded uncertain and nervous. Others hear that, they prob felt sympathy for poor me trying my best to make my point 😂. Working displaying that confidence to match my experience is my next step because seniors lead. They have the experience and they use it to guide teams.
  • 2
    @Bubbles As far as failing in the code and service realm, you dont learn without failure. Ive got a guy at my org who works on the same stuff i do but he was a CS professor at a university prior to working here as if thats not intimidating! He messes up plenty. Submits changes that break in production, introduces new defects. No one beats him down about it cause what he works on is crazy difficult just like all of the things we work on. As long as we learn and become better from them and mistakes are the absolute best way to learn
  • 1
    @hjk101 its definitely contextual. If your contract, it might be better to do this entirely on your own time. If your contract you prob wont have the time cause deadlines and demands are more concrete. Then you got me at a fair sized corp who has enough free time (not my fault. Id love for all my time to be occupied with features and interesting problems) to put at least an hour a day into other things. In the end, these side projects build me as a developer, they keep me happy as i feel like im doing something to better myself and it eventually feeds back into the company. Bettering yourself as a developer is doping your company a favor. Most companies have a 80/20 rule anyways for learning
  • 1
    @Condor thank ya mate
  • 1
    @dUcKtYpEd that’s what I want too, an environment where people will support me while I learn instead of leaving me alone majority of the time, but I’m also just not a confident person but I can always work on it.
  • 1
    Well said bro!
  • 1
    For sure, do all that and come up with amazing solutions to big problems and take time out of your social and family life to do so and you will still have the great privilege of being overlooked for promotions if you are a woman...
    Tell junior devs to stop putting all their time and effort towards making someone else money. Find a problem you want to solve for you and work to solve that. And don’t sacrifice your own time to do work for a company that will grow to take advantage of that time.
  • 1
    @morphplay I mean, that’s the end goal. Make your own solutions and be your own boss or get payed way too much to handle someone else’s problems
Add Comment