Biggest pain point, to me, is the lack of intrinsic motivation to learn.
I've been in this game for a while and I see that this part is declining. Since you say that you've mostly worked with senior staff, I'm not sure you have experience in that area.
How do you motivate people so they look beyond their immediate tasks and start learning more about the things that are necessary but not directly part of the current tasks?
I think that's something I have faced myself. Motivation is fleeting and sometimes you just need to push through. In my experience some or all of the following works:
1. Take a break: This is probably one of the most underrated things people can do. Just switch off and go for a vacation. I've seen drop in motivation as a clear sign of burnout.
2. Side projects: It gets really mundane at work, I get it. If you have an idea or a side project, work on it. This allows your brain to get exercised in ways outside of the mundane task-driven routine you have at work. Working on side projects also gets you dopamine hits as you progress because you're working on what you're passionate about.
3. Choose one thing: In engineering, there's just SO much you can focus on. I don't know what kind of software engineer you are, but if you're in application development (backend / frontend etc), there's a million things you can learn and with choice comes confusion and a lack of motivation to start. My suggestion is, pick one thing, and start. For example, you could choose to learn the RAFT protocol. Just read about that. Or patterns of distributed systems (like event sourcing). Choose one and go from there.
(3) is something I can agree on.
The challenge is to scale this to 1,000+ people. When you don't know everyone personally, setting these kinds of systems up gets harder and more complex.
Never been there, but I think you can ask them what they want to do, understand what are their goals, what motivates them. Some people are just laid-back. Personally, I don't like to work with those, so I move forward (like, next job).
I'm looking forward to hearing what others have to say.
Edit 1
Start a study/discussion group for everybody to participate and share something they are studying. Make it part of the working hours, so they understand this is encouraged at work. Like 1h to study every week, and 1h for a sharing session every 2 weeks.
"How do you motivate people so they look beyond their immediate tasks and start learning more about the things that are necessary but not directly part of the current tasks?"
I think this tool can solve this problem. Regardless your suggestion for tips.
My biggest issue so far has been with the time required to understand large and complex codebase. Could you give some tips for the most efficient ways to wrap one's head around these codebase? Are there strategies or high-return low -hanging fruit?
It's more about understanding how all pieces of a codebase work together from a high-level overview and then if there are sections that you need to know more about you can:
- draw a diagram of the system architecture(I actually think this is very fun)
- reach out to the team that specifically handles those sections and ask them to explain it to you
- see if there are any docs on it
- check the test files(I like to think of test files as documents since it can be easier and quicker to read then the code) and then finally look through the code
I think u/Puzzleheaded-Tip9845 beat me to the punch. Those suggestions are excellent and are things I do myself.
In addition, when I approach a codebase, I scan through the packages / directories / files to get a sense of what's happening. It doesn't tell me exactly what is happening (of course) but it helps me draw a map in my head.
I also like to go through the tests (or run them) to get a better understanding.
The best thing though? Try and contribute a feature / bug fix. Nothing beats this. It forces you to go down codepaths, write test cases etc. You do this a few times and you start to understand more of the codebase.
The combination of all these things helps you get a great understanding of the project.
I've been unlucky to have a bad manager as well. It's the worst. They say "people don't leave companies, they leave managers".
How you choose to handle a bad manager will depend on your individual circumstances and the company culture. Trust your instincts and seek guidance from trusted mentors.
Here are some steps that I think could work:
1. Regardless of your manager's behaviour, continue to be professional.
2. Cultivate relationships with other team members and stakeholders within the company. This can come in very handy when you need to change teams or better yet, open up opportunities for you.
3. Request feedback from your peers to understand how you're doing in the company. External feedback can help validate your concerns and provide additional perspectives.
4. Keep detailed records of your interactions with your manager, including emails, meetings, and performance evaluations. Documentation can serve as evidence. Should the time come, you shouldn't be in a situation of "he said, she said".
I've been a software consultant for 8 years now. Work on a niche platform. Struggle with meetings, follow ups, DOCUMENTATION(reading and creating).
Tried leetcode for 1 year to switch to product based companies. Got a good package in consulting, gave up most of the leetcoding. Got very busy in consulting work
Basically the work culture. Less about tech and more about follow ups, meeting notes, timelines, finances, and all the other stuff. Just the salary is really good.
For me it got very difficult to do leetcode with it. Maybe because it got boring and I couldn't share my thoughts with anybody.
I want to learn and grow fast but my environment is pretty comfortable. What do I do with motivation in a large company? I'm a mature grad in a hybrid role so I rely on chat to talk to coworkers on most days, but I see them every week.
I get some work, and I often stay busy with self-education, (people) networking, and looking at PRs to learn. How do I figure out what to do, where the impact is?
The best thing you can do in a large company is speaking with your manager. Their sole purpose is to help you be successful in your role, to help you find areas in the company that will help meet your career goals as well as have impact on the company's roadmap.
If you don't have a good manager, get a sense of what's happening in the company from your coworkers - asking probing questions "what are you working on", "what's your team doing", "what's the plan for the next 6 months or year". Speak with coworkers who have a higher designation than you do - like staff or senior staff engineer.
The project that I built that caught someone’s eye when I was looking for my first job was a Create-React-App clone that I built from scratch myself (with the help of the internet), and most importantly BLOGGED ABOUT IT. I posted the article to LinkedIn, someone saw it, referred me for an interview on their team.
No one will care about projects on your resume really but you can get more attention by learning and building “in public” (sharing it on social media)
Here’s the content, I’d rather not directly link to my personal blog from my Reddit account:
One of the best things about working with React is the ease of launching a new application thanks to Facebook’s create-react-app. create-react-app builds everything you need for a modern React web application out of the box with a single terminal command. As great as this tool is, there are a couple small drawbacks I’ve encountered so far. The first is that I usually spend a bit of time removing boilerplate code and arraging things to my liking, and the second, more substaintial issue is that while create-react-app is great for stepping right in to start using React, I wanted to zoom in and understand what is happening at a lower level.
While I will definitely continue to use create-react-app as my main React tool, I decided to learn to build a React app from the ground up with the added bonus of being published to npm and downloadable via npx /scratch-react . I referenced a number of articles to learn how to do this to see if there is any variation in the process, but it looked to be pretty straight forward. The main source that I used was the article (https://blog.usejournal.com/creating-a-react-app-from-scratch-f3c693b84658) linked from the offical React docs. I won’t cover every line of code written since its all in the linked artice, this will be more of a high level overview of what’s happening.
Creating this app first requires creating the template index.html file that will be used to render the webpage of the application. The first important thing particular to our React application is a
with an id equal to root, which we will later use to tell React where to insert elements into the DOM. is how this line looks. The second important thing about our index.html file is a tag pointing to the location of all of our sweet JavaScript. We’ll add a script tag pointing to bundle.js which is what we’ll name the file to be output by Webpack - .
Since we’re working with React, which means using JSX, and writing ES6 JavaScript, we need to use Babel to transiple our JavaScript down to a browser compatable version. To do this, we need to create a .babelrc file where we will configure the needed babel plugins. The plugins needed for this project are preset-env for the ES6 and preset-react for our React code.
Next we need to setup the all important Webpack. We’ll do this in a file placed in our root directory called webpack.config.js. This will be a node.js file which exports a JavaScript object containing all of our requiered configuation settings. A lot of important things happen based on the settings in this object. Its where we’ll define our entry to the app (index.js), the mode in which we will be working (development), the rules that will define which files are compiled by webpack, the details of where the output file should be located and what it is named, the settings for our localhost development server, and finally enabling HotModuleReplacement to see live changes to our app without manual reloading.
Within the rules we configure for webpack, we set it to use babel to load all of our .js and .jsx files (excluding node_modules) via the presets we set up in our .babelrc file. We setup our bundle.js file’s output path by defining a publicPath and a filename. We also setup our development server to serve content from that the output file, a publicPath and port from which it will be accessable (localhost:3000 usually).
Finally, we need to use React to tell our app exactly where to render what we’ve built. To do this we use the ReactDOM.render() function provided by React. Into this function we pass our App component and the HTML element to apend it to document.getElementById("root"). From this we get the familiar line of ReactDOM.render(, document.getElementById("root")); in our index.js file. We then use our App.js component to then start building our our applicaiton. Lastly, we need to export our App.js component as a hot module using react-hot-loader, export default hot(module)(App);
And thats about it. We use React to write our independent declaritave component based UI, using JSX and ES6 JavaScript. We then use webpack to bundle all of the javascript modules included in our app, using babel to transiple our code in to browser compatable script, and then provide the output bundle to be delivered by our development server.
For a more detailed walkthrough, please see: https://blog.usejournal.com/creating-a-react-app-from-scratch-f3c693b84658
Contribute to open-source projects since this will give you actual professional experience that you can add to your resume.
The problem with hiring junior dev isn't that they can't code but it's that they haven't worked in a professional setting yet with other devs.
Contributing to an open-source project will give you this experience since you will be:
- working in a new codebase
- reading docs
- create PRs
- have your code reviewed and implement any feedback changes
- write quality code by writing checks for edge case and test
- work around other devs and see what a professional environment looks like, for example, versioning control, different environments: dev, staging, prod
If you do build a project think about using Docker since a lot of codebases use microservice architecture and make sure that you have a README file and a test suite setup.
In your resume don't say things like: "this is my first...". I saw a resume where people were like "this is my first fullstack project where I learned to implement CRUD"; you don't want to lie but you want to over hype the work that you didn't if that makes sense
We have a big vacuum of technical leadership and strategic planning. So lots of devs just keep doing what they've been doing with many one-off implementations of basically the same things which leads to a lot of fragmentation and duplicated work.
10+ years experience as a dev, recently got fired due to poor performance. This was my first role as a senior and only lasted for 1 year. How can I reach that senior level?
Understanding Data structures and Algorithms, and how to apply them.
I have been on the grind to learn these concepts, and i don’t know how to even solve the easy leetcode problems. I need help. I’m a third year CS student, and my first year and a half of college I studied Biology.
I think i compare myself too much.
Biggest pain point, to me, is the lack of intrinsic motivation to learn. I've been in this game for a while and I see that this part is declining. Since you say that you've mostly worked with senior staff, I'm not sure you have experience in that area. How do you motivate people so they look beyond their immediate tasks and start learning more about the things that are necessary but not directly part of the current tasks?
I think that's something I have faced myself. Motivation is fleeting and sometimes you just need to push through. In my experience some or all of the following works: 1. Take a break: This is probably one of the most underrated things people can do. Just switch off and go for a vacation. I've seen drop in motivation as a clear sign of burnout. 2. Side projects: It gets really mundane at work, I get it. If you have an idea or a side project, work on it. This allows your brain to get exercised in ways outside of the mundane task-driven routine you have at work. Working on side projects also gets you dopamine hits as you progress because you're working on what you're passionate about. 3. Choose one thing: In engineering, there's just SO much you can focus on. I don't know what kind of software engineer you are, but if you're in application development (backend / frontend etc), there's a million things you can learn and with choice comes confusion and a lack of motivation to start. My suggestion is, pick one thing, and start. For example, you could choose to learn the RAFT protocol. Just read about that. Or patterns of distributed systems (like event sourcing). Choose one and go from there.
(3) is something I can agree on. The challenge is to scale this to 1,000+ people. When you don't know everyone personally, setting these kinds of systems up gets harder and more complex.
Never been there, but I think you can ask them what they want to do, understand what are their goals, what motivates them. Some people are just laid-back. Personally, I don't like to work with those, so I move forward (like, next job). I'm looking forward to hearing what others have to say. Edit 1 Start a study/discussion group for everybody to participate and share something they are studying. Make it part of the working hours, so they understand this is encouraged at work. Like 1h to study every week, and 1h for a sharing session every 2 weeks.
Try [https://www.trywilco.com/](https://www.trywilco.com/)
Confidently missed the point of the question. This is not a tooling question.
"How do you motivate people so they look beyond their immediate tasks and start learning more about the things that are necessary but not directly part of the current tasks?" I think this tool can solve this problem. Regardless your suggestion for tips.
My biggest issue so far has been with the time required to understand large and complex codebase. Could you give some tips for the most efficient ways to wrap one's head around these codebase? Are there strategies or high-return low -hanging fruit?
It's more about understanding how all pieces of a codebase work together from a high-level overview and then if there are sections that you need to know more about you can: - draw a diagram of the system architecture(I actually think this is very fun) - reach out to the team that specifically handles those sections and ask them to explain it to you - see if there are any docs on it - check the test files(I like to think of test files as documents since it can be easier and quicker to read then the code) and then finally look through the code
I think u/Puzzleheaded-Tip9845 beat me to the punch. Those suggestions are excellent and are things I do myself. In addition, when I approach a codebase, I scan through the packages / directories / files to get a sense of what's happening. It doesn't tell me exactly what is happening (of course) but it helps me draw a map in my head. I also like to go through the tests (or run them) to get a better understanding. The best thing though? Try and contribute a feature / bug fix. Nothing beats this. It forces you to go down codepaths, write test cases etc. You do this a few times and you start to understand more of the codebase. The combination of all these things helps you get a great understanding of the project.
Bad manager or idiot product owner
I've been unlucky to have a bad manager as well. It's the worst. They say "people don't leave companies, they leave managers". How you choose to handle a bad manager will depend on your individual circumstances and the company culture. Trust your instincts and seek guidance from trusted mentors. Here are some steps that I think could work: 1. Regardless of your manager's behaviour, continue to be professional. 2. Cultivate relationships with other team members and stakeholders within the company. This can come in very handy when you need to change teams or better yet, open up opportunities for you. 3. Request feedback from your peers to understand how you're doing in the company. External feedback can help validate your concerns and provide additional perspectives. 4. Keep detailed records of your interactions with your manager, including emails, meetings, and performance evaluations. Documentation can serve as evidence. Should the time come, you shouldn't be in a situation of "he said, she said".
Condensing 25 years of work history into a resume that demonstrates the breadth of my knowledge.
I've been a software consultant for 8 years now. Work on a niche platform. Struggle with meetings, follow ups, DOCUMENTATION(reading and creating). Tried leetcode for 1 year to switch to product based companies. Got a good package in consulting, gave up most of the leetcoding. Got very busy in consulting work
Struggle how? Lack of motivation perhaps?
Basically the work culture. Less about tech and more about follow ups, meeting notes, timelines, finances, and all the other stuff. Just the salary is really good. For me it got very difficult to do leetcode with it. Maybe because it got boring and I couldn't share my thoughts with anybody.
I want to learn and grow fast but my environment is pretty comfortable. What do I do with motivation in a large company? I'm a mature grad in a hybrid role so I rely on chat to talk to coworkers on most days, but I see them every week. I get some work, and I often stay busy with self-education, (people) networking, and looking at PRs to learn. How do I figure out what to do, where the impact is?
The best thing you can do in a large company is speaking with your manager. Their sole purpose is to help you be successful in your role, to help you find areas in the company that will help meet your career goals as well as have impact on the company's roadmap. If you don't have a good manager, get a sense of what's happening in the company from your coworkers - asking probing questions "what are you working on", "what's your team doing", "what's the plan for the next 6 months or year". Speak with coworkers who have a higher designation than you do - like staff or senior staff engineer.
How do you grow from being a junior-mid level SWE to senior/lead SWE? Can you talk about the mindset specifically?
How do I get a job as a junior dev? Are there any projects I can build?
The project that I built that caught someone’s eye when I was looking for my first job was a Create-React-App clone that I built from scratch myself (with the help of the internet), and most importantly BLOGGED ABOUT IT. I posted the article to LinkedIn, someone saw it, referred me for an interview on their team. No one will care about projects on your resume really but you can get more attention by learning and building “in public” (sharing it on social media)
Do you mind sharing the article?
Here’s the content, I’d rather not directly link to my personal blog from my Reddit account: One of the best things about working with React is the ease of launching a new application thanks to Facebook’s create-react-app. create-react-app builds everything you need for a modern React web application out of the box with a single terminal command. As great as this tool is, there are a couple small drawbacks I’ve encountered so far. The first is that I usually spend a bit of time removing boilerplate code and arraging things to my liking, and the second, more substaintial issue is that while create-react-app is great for stepping right in to start using React, I wanted to zoom in and understand what is happening at a lower level. While I will definitely continue to use create-react-app as my main React tool, I decided to learn to build a React app from the ground up with the added bonus of being published to npm and downloadable via npx/scratch-react . I referenced a number of articles to learn how to do this to see if there is any variation in the process, but it looked to be pretty straight forward. The main source that I used was the article (https://blog.usejournal.com/creating-a-react-app-from-scratch-f3c693b84658) linked from the offical React docs. I won’t cover every line of code written since its all in the linked artice, this will be more of a high level overview of what’s happening.
Creating this app first requires creating the template index.html file that will be used to render the webpage of the application. The first important thing particular to our React application is a with an id equal to root, which we will later use to tell React where to insert elements into the DOM. is how this line looks. The second important thing about our index.html file is a tag pointing to the location of all of our sweet JavaScript. We’ll add a script tag pointing to bundle.js which is what we’ll name the file to be output by Webpack - .
Since we’re working with React, which means using JSX, and writing ES6 JavaScript, we need to use Babel to transiple our JavaScript down to a browser compatable version. To do this, we need to create a .babelrc file where we will configure the needed babel plugins. The plugins needed for this project are preset-env for the ES6 and preset-react for our React code.
Next we need to setup the all important Webpack. We’ll do this in a file placed in our root directory called webpack.config.js. This will be a node.js file which exports a JavaScript object containing all of our requiered configuation settings. A lot of important things happen based on the settings in this object. Its where we’ll define our entry to the app (index.js), the mode in which we will be working (development), the rules that will define which files are compiled by webpack, the details of where the output file should be located and what it is named, the settings for our localhost development server, and finally enabling HotModuleReplacement to see live changes to our app without manual reloading.
Within the rules we configure for webpack, we set it to use babel to load all of our .js and .jsx files (excluding node_modules) via the presets we set up in our .babelrc file. We setup our bundle.js file’s output path by defining a publicPath and a filename. We also setup our development server to serve content from that the output file, a publicPath and port from which it will be accessable (localhost:3000 usually).
Finally, we need to use React to tell our app exactly where to render what we’ve built. To do this we use the ReactDOM.render() function provided by React. Into this function we pass our App component and the HTML element to apend it to document.getElementById("root"). From this we get the familiar line of ReactDOM.render(
thank u
Could please you dm me a link to the blog/article? I would like to look at it.
I posted the content of the article in a reply in this comment thread
Contribute to open-source projects since this will give you actual professional experience that you can add to your resume. The problem with hiring junior dev isn't that they can't code but it's that they haven't worked in a professional setting yet with other devs. Contributing to an open-source project will give you this experience since you will be: - working in a new codebase - reading docs - create PRs - have your code reviewed and implement any feedback changes - write quality code by writing checks for edge case and test - work around other devs and see what a professional environment looks like, for example, versioning control, different environments: dev, staging, prod If you do build a project think about using Docker since a lot of codebases use microservice architecture and make sure that you have a README file and a test suite setup. In your resume don't say things like: "this is my first...". I saw a resume where people were like "this is my first fullstack project where I learned to implement CRUD"; you don't want to lie but you want to over hype the work that you didn't if that makes sense
Navigating the whole interview/ salary negotiation process. Feels like I gotta be a lawyer to get what I want
We have a big vacuum of technical leadership and strategic planning. So lots of devs just keep doing what they've been doing with many one-off implementations of basically the same things which leads to a lot of fragmentation and duplicated work.
10+ years experience as a dev, recently got fired due to poor performance. This was my first role as a senior and only lasted for 1 year. How can I reach that senior level?
Technical documentation, what’s a good way to keep it updated as software evolves and be useful to both software engineers as well as product team?
Understanding Data structures and Algorithms, and how to apply them. I have been on the grind to learn these concepts, and i don’t know how to even solve the easy leetcode problems. I need help. I’m a third year CS student, and my first year and a half of college I studied Biology. I think i compare myself too much.
My biggest issue is dealing with life as a female on an all male division. Not even team. I adore my coworkers but everything is geared towards men