You will ask many, many questions(letterstoanewdeveloper.com)
letterstoanewdeveloper.com
You will ask many, many questions
https://letterstoanewdeveloper.com/2022/01/17/you-will-ask-many-many-questions/
48 comments
Please do jump on me at 9 when you start your day. I will already be done with all the emails and messages from last night and people in other timezones as I started working two hours ago.
Before you go for your lunch send me your questions. I might be eating, I might not. I might be out taking a walk. No matter, send me your questions and I will answer when I have time. Make sure you ask them in an async friendly way where you tell me what you already tried, what the actual error messages are if it's some error you are getting. Give me as much information up front as you can think of.
Don't wait until 3pm to ask your questions. You won't get an answer until the next day as I'm already off because I started early. Timebox your struggling. After half an hour, shoot me a message. If I'm around I'll answer right away and try to get you unstuck so that you can learn and make good use of the rest of your day.
All that to say: do not assume. Ask. Not everyone is the same. Not everyone has the same schedule. What works for Mc91 does not apply to everyone.
Before you go for your lunch send me your questions. I might be eating, I might not. I might be out taking a walk. No matter, send me your questions and I will answer when I have time. Make sure you ask them in an async friendly way where you tell me what you already tried, what the actual error messages are if it's some error you are getting. Give me as much information up front as you can think of.
Don't wait until 3pm to ask your questions. You won't get an answer until the next day as I'm already off because I started early. Timebox your struggling. After half an hour, shoot me a message. If I'm around I'll answer right away and try to get you unstuck so that you can learn and make good use of the rest of your day.
All that to say: do not assume. Ask. Not everyone is the same. Not everyone has the same schedule. What works for Mc91 does not apply to everyone.
Thanks for the timebox hint. I should apply that more often. Realise that I'm stuck, struggling, break and regroup.
Can't you just get back to them when you get back to them? Why should anyone know what you are doing down to the minute?
Seconded. The person asking questions is just trying to get the questions into the queue. I doubt they are expecting an immediate response. And if they are, that’s a different question.
Even if I have a relationship with someone where this is well understood, I still think it's helpful to preface these kinds of blocks of text with something like "Hey, nothing high priority here, so you can take your time before getting back to me"
I agree, I like to start with “Not urgent, but”
Yeah, sounds like they should just message back "Hey, I'll take a look at these in an hour or so, after I get caught up"
Actually I've told some people "don't struggle on something all day and then at 4:45PM tell me you haven't made any progress and ask for help" many times, and I still get the 4:45PM messages from them. It's not like the idea of telling them these things did not occur to me.
Counterpoint: it's okay to set expectations for how you'd like to be interacted with, by your team members.
Oof. Block out time on your calendar if you need not be disturbed at certain times of the day. Expecting everyone else you work with to understand your idiosyncratic system is not a reasonable thing to do.
Please ask me everything at 9am by 10am I will be too busy and into something. Tell me you are struggling at 4:45 and we'll deal with it tomorrow. Telling me at 4pm means we have to deal with it now when I have planned other activities.
That’s a grumpy dev if I’ve seen one
Ask questions on tickets, outline how far you got, where you got stuck, context, details. This is super helpful for posterity. And after you find the answer, update or create documentation for your future self and others.
Developer Superpowers:
* Learn to ask questions on stackoverflow that don't get deleted. Try, read feedback, try again.
* Learn to ask yourself questions. You'll be surprised how powerful how your own deductive powers can be.
* Be ready to be wrong. That's when you learn something new.
* Most companies have safeguards to prevent a newbie from breaking production. It's ok if you don't have 100% confidence in your code. If they don't, that's a lesson for them.
* Learn to ask questions on stackoverflow that don't get deleted. Try, read feedback, try again.
* Learn to ask yourself questions. You'll be surprised how powerful how your own deductive powers can be.
* Be ready to be wrong. That's when you learn something new.
* Most companies have safeguards to prevent a newbie from breaking production. It's ok if you don't have 100% confidence in your code. If they don't, that's a lesson for them.
"* Be ready to be wrong. That's when you learn something new."
This comes naturally to me as a beginner, since I get slapped in the face with my wrongness pretty regularly. And I know that, barring rare outliers, this is the experience of most people starting out. What bugs me is that some people have the attitude that they have never sucked, and were awesome from day 1. What gives?
This comes naturally to me as a beginner, since I get slapped in the face with my wrongness pretty regularly. And I know that, barring rare outliers, this is the experience of most people starting out. What bugs me is that some people have the attitude that they have never sucked, and were awesome from day 1. What gives?
You should probably keep a log of the questions and answers, and put it in the team wiki.
You likely are going through the first full reconstruction of the dev environment in 1-6 months, maybe even a year. Documentation is GUARANTEED to be stale. Critical bits of info glossed over.
This turns the burden of questions into a constructive team exercise that pays a dividend.
You likely are going through the first full reconstruction of the dev environment in 1-6 months, maybe even a year. Documentation is GUARANTEED to be stale. Critical bits of info glossed over.
This turns the burden of questions into a constructive team exercise that pays a dividend.
I saw this advice online somewhere ages ago and I've found it to be incredibly useful--
Before you ask a question, try to answer it yourself for fifteen minutes. If you still don't know, then ask. This way, you'll know that it's not a dumb question. But if it really is a good question, you won't be struggling for hours before asking anybody about it. You'll also learn a lot trying to solve it, and remember the answer better than if someone just told you.
Before you ask a question, try to answer it yourself for fifteen minutes. If you still don't know, then ask. This way, you'll know that it's not a dumb question. But if it really is a good question, you won't be struggling for hours before asking anybody about it. You'll also learn a lot trying to solve it, and remember the answer better than if someone just told you.
This is good advice but there's an important caveat. After spending 15 minutes trying to answer the question you should still ask the question even if you have an answer. The problem with the advice is that it implies questions have one good answer. For most dev questions there will be many answers, and a lot of them will be awful.
For example, if a junior asks themselves "How do I sort this list of things?", they'll probably come up with a solution inside of 15 minutes if they're good. That solution probably won't pass a code review though.
The issue is that as a new dev you don't have the depth of knowledge to understand whether you solution is actually a good one or not. Talking about your idea with the rest of the team is critical for learning about some of the nuances around solving problems.
(This also applies to more senior devs too. Everyone should be talking about what they're doing occasionally.)
For example, if a junior asks themselves "How do I sort this list of things?", they'll probably come up with a solution inside of 15 minutes if they're good. That solution probably won't pass a code review though.
The issue is that as a new dev you don't have the depth of knowledge to understand whether you solution is actually a good one or not. Talking about your idea with the rest of the team is critical for learning about some of the nuances around solving problems.
(This also applies to more senior devs too. Everyone should be talking about what they're doing occasionally.)
If the team will have to solve every problem you encounter, they will eventually conclude you are useless and unable to do work. I mean come on, with this strategy, you contribution to team will be negative.
This kind of advice really goes overboard and harms people who would listen to it.
This kind of advice really goes overboard and harms people who would listen to it.
Firstly, we talking about new devs. Once you get a bit more experience you start making more of these calls yourself. Secondly, sanity checking an approach to solving a problem with rest of the team is just basic common sense - someone else might be solving the same problem, or have some insight into a part of the code you haven't touched, or have experience of the same issue on another team. That never goes away regardless of your level.
The suggestion that you should solve problems on your own is far more harmful. Software development is a team sport.
The suggestion that you should solve problems on your own is far more harmful. Software development is a team sport.
With certain problems what I do is to sketch a rough Merge Request and share that with others to confirm the general approach.
It works wonders, and discussing actual code makes it easier for most people than discussing abstract concepts.
It works wonders, and discussing actual code makes it easier for most people than discussing abstract concepts.
Reading this makes me feel like a super slow learner. I've experienced the "15 minute rule" before and for me, 15 minutes goes by so quick.
I might have a question, try to find the answer, find several answers and have to dig into them to understand the answer to determine which is likely the better one etc. But this in no way takes 15 minutes, could be 30 45 60 or more. It's like I get a step closer and each "phase" is a new 15 minutes and so a new question to ask.
I might have a question, try to find the answer, find several answers and have to dig into them to understand the answer to determine which is likely the better one etc. But this in no way takes 15 minutes, could be 30 45 60 or more. It's like I get a step closer and each "phase" is a new 15 minutes and so a new question to ask.
It should be noted it can be really easy to get a reputation for asking too many questions.
That's why you spread your questions out, so no one person knows everything you don't know
More than this, you must ask them of many, many different people, in different ways. Whatever it is you are doing, it serves many people, in extremely different ways. Ask, then also research patterns of behavior, because sometimes people omit, lie, forget, and so on. I am not afraid to look like a total dumbass, either.
My current job, I'm three years in, still learning new things that are adjacent to my job.
My current job, I'm three years in, still learning new things that are adjacent to my job.
You need to ask questions, but also realize that 50-99% of them, depending on what you're working on, will be answered by doing a Google search and clicking the first Stack Overflow link you see.
This has not been true anywhere I've worked at. There's usually tons of tribal knowledge, internal tooling/software, external software thats just rarely used, and code base quirks. None of which you'll find on google/stack overflow.
Have you worked with new developers? Especially with the ones from cultures where asking a lot of questions is culturally expected?
I did. 90% of their questions were 1 Google search and 1 stack overflow click away.
I did. 90% of their questions were 1 Google search and 1 stack overflow click away.
I think this guy was talking about questions of new devs in general. And I support the statement that most will be found in the first result of Google search.
Your company might be different, and sure some knowledge of system is only available from seniors, but your company still will have enough documentation, if a search for keywords in it likely to get results.
Your company might be different, and sure some knowledge of system is only available from seniors, but your company still will have enough documentation, if a search for keywords in it likely to get results.
#1 sign of a developer who does not work out?
They do not ask enough questions. Or do not admit to not understanding something.
In some cases its a cultural issue. For example working with some (not all) developers in Asia, its culturally negative to admit you don't know something. I've found ways to work around this and bring some really talented people into good heights.
But for western/anglosphere developers, it's the kiss of death.
I've found that Eastern European developers generally believe they are the best (even when they aren't). For instance, a young developer I eventually hired asked me if I knew something about a topic (I have for decades) in a very condescending way. This happened multiple times from different Eastern European developers. Once you understand that cultural imperative, you can have really great coding relationships with those developers.
#2 sign of a bad developer?
They don't do enough reading. I mean they don't keep up with the industry, don't follow HN, don't keep up with the latest news on the tech stack they use, etc.
They do not ask enough questions. Or do not admit to not understanding something.
In some cases its a cultural issue. For example working with some (not all) developers in Asia, its culturally negative to admit you don't know something. I've found ways to work around this and bring some really talented people into good heights.
But for western/anglosphere developers, it's the kiss of death.
I've found that Eastern European developers generally believe they are the best (even when they aren't). For instance, a young developer I eventually hired asked me if I knew something about a topic (I have for decades) in a very condescending way. This happened multiple times from different Eastern European developers. Once you understand that cultural imperative, you can have really great coding relationships with those developers.
#2 sign of a bad developer?
They don't do enough reading. I mean they don't keep up with the industry, don't follow HN, don't keep up with the latest news on the tech stack they use, etc.
I'm late to this, but you can't post national/ethnic/regional/racial slurs like this to HN, regardless of which group you've had a problem with.
I noticed that you've done this at least once before about a different part of the world ("a bit of an asshole"). Can you please not post like this to HN? We all have these sorts of prejudices because we all overgeneralize from limited experience–but when we broadcast them to thousands of people, which is what you're doing when posting to HN, it tends to produce flamewars, which we don't want here.
https://news.ycombinator.com/newsguidelines.html
I noticed that you've done this at least once before about a different part of the world ("a bit of an asshole"). Can you please not post like this to HN? We all have these sorts of prejudices because we all overgeneralize from limited experience–but when we broadcast them to thousands of people, which is what you're doing when posting to HN, it tends to produce flamewars, which we don't want here.
https://news.ycombinator.com/newsguidelines.html
> I've found that Eastern European developers generally believe they are the best (even when they aren't)
I've been this Eastern European developer and seen others. A 100% accurate assessment. I'd go as far as to say that this animalistic bravado must not be encouraged.
Ultimately, it comes from a place of poor self-awareness. There's something about EE cultural/historic context that breeds a lot of brilliant zombies.
So as with all un-self-aware team members ([1]), EE developers with these traits can have a serious detrimental effect on the culture, unless kept in check. My suggestions:
* Call them out on toxic behaviour, so that it doesn't become normalised.
* Make them directly accountable for their work. EE devs relish the idea of being a shadowy IC of outsized but unacknowledged importance. Don't let them mythologise their own status.
[1]: https://hbr.org/2018/10/working-with-people-who-arent-self-a...
I've been this Eastern European developer and seen others. A 100% accurate assessment. I'd go as far as to say that this animalistic bravado must not be encouraged.
Ultimately, it comes from a place of poor self-awareness. There's something about EE cultural/historic context that breeds a lot of brilliant zombies.
So as with all un-self-aware team members ([1]), EE developers with these traits can have a serious detrimental effect on the culture, unless kept in check. My suggestions:
* Call them out on toxic behaviour, so that it doesn't become normalised.
* Make them directly accountable for their work. EE devs relish the idea of being a shadowy IC of outsized but unacknowledged importance. Don't let them mythologise their own status.
[1]: https://hbr.org/2018/10/working-with-people-who-arent-self-a...
I guess I can't really agree it's a cultural/regional thing as the ideas you describe I see in _every regional team I have in my company_.
- Some people come in with full bravado, "I was the best at my last job so I'm the best here", "I can never be wrong attitudes"
- Some people are afraid to look stupid or think they'll get looked down upon or even fired for asking dumb questions
- Others just want to focus exclusively on the one task they're dedicated to and not a single bit more and will flee from anything outside of their area of knowledge and forever are locked into "I do X and nothing else"
- Finally, there are those that realized none of the above is a requirement, and it's fine to ask questions and even better, to be curious
The final group are my most successful engineers/devs because they are insatiably curious. They ask questions in a good way, explain their understanding of a situation first and how they arrive at conclusions, and then want to understand how you got to yours and if they maybe have missed a better way. My US teams, Latin American teams, Eastern European teams, Asian teams, they all have their persons who just get above the usual tropes of work and just want to learn and make cool things, but this is a rare individual person regardless of their cultural background.
I've even seen some who started with such attitudes of bravado and arrogance and once they realized "well damn, I'm not the brightest star in the sky by a long shot", they humble up pretty fast and realize they have an opportunity to get even better and they go for it. It happens plenty, though not as much as I would prefer.
I don't think it's about culture, I think it's just individual personalities which transcend borders.
- Some people come in with full bravado, "I was the best at my last job so I'm the best here", "I can never be wrong attitudes"
- Some people are afraid to look stupid or think they'll get looked down upon or even fired for asking dumb questions
- Others just want to focus exclusively on the one task they're dedicated to and not a single bit more and will flee from anything outside of their area of knowledge and forever are locked into "I do X and nothing else"
- Finally, there are those that realized none of the above is a requirement, and it's fine to ask questions and even better, to be curious
The final group are my most successful engineers/devs because they are insatiably curious. They ask questions in a good way, explain their understanding of a situation first and how they arrive at conclusions, and then want to understand how you got to yours and if they maybe have missed a better way. My US teams, Latin American teams, Eastern European teams, Asian teams, they all have their persons who just get above the usual tropes of work and just want to learn and make cool things, but this is a rare individual person regardless of their cultural background.
I've even seen some who started with such attitudes of bravado and arrogance and once they realized "well damn, I'm not the brightest star in the sky by a long shot", they humble up pretty fast and realize they have an opportunity to get even better and they go for it. It happens plenty, though not as much as I would prefer.
I don't think it's about culture, I think it's just individual personalities which transcend borders.
This syncs with my experience. The ones that think they are better than everyone else and don’t have any humility are the hardest. They tend to break things, write 5x more code than needed then stay defensive and finger point instead of fixing things.
I have worked with a few juniors who actually were better than everyone. In all cases they were approachable, humble, asked questions and then were swooped up by a company like google.
I have worked with a few juniors who actually were better than everyone. In all cases they were approachable, humble, asked questions and then were swooped up by a company like google.
I'd push back pretty hard on #2 bring a strong signal, depending o on what you mean by successful I guess. Making it to a staff/whatever role where your making best practices decisions org wide? Yeah I can see it. Being a successful senior slinging mostly bug free code? Meh. Gimmie someone with domain expertise any day
Well, assume you are using PHP. It’s great to work with someone who knows the ins and outs of the version they are using. What’s new and what’s deprecated.
That comes from reading about the tools.
Domain experience is a given. You need that to do the job regardless.
Pattern reuse is also critical - or you end up reinventing the wheel for every little thing.
That comes from reading about the tools.
Domain experience is a given. You need that to do the job regardless.
Pattern reuse is also critical - or you end up reinventing the wheel for every little thing.
Domain expertise is absolutely not a given. For example: I'd wager very few devs working on healthcare apps have any experience working in healthcare. Very few ad tech devs have ever run an ad campaign.
In regards to staying up to date on php. Surely best practices aren't changing very often? For myself, I look forward to some niceties coming in my tech stack, but I honestly care very little if literally anyone at my org is aware of them. We won't be retrofitting old code and using it in new code will come with all the little gritty interfacing with old code issues that always surface.
So why should I judge them on something that will have little or no impact on their day to day and when it does come around the people who do keep up are more than happy to show it off and evangelize?
In regards to staying up to date on php. Surely best practices aren't changing very often? For myself, I look forward to some niceties coming in my tech stack, but I honestly care very little if literally anyone at my org is aware of them. We won't be retrofitting old code and using it in new code will come with all the little gritty interfacing with old code issues that always surface.
So why should I judge them on something that will have little or no impact on their day to day and when it does come around the people who do keep up are more than happy to show it off and evangelize?
> I've found that Eastern European developers generally believe they are the best (even when they aren't).
A few years ago, I worked with a developer from Eastern Europe who told me he believed the developers in the European part of the company were better than those in the US part of the company.
I found this to be a bizarre statement (and not true) and I don't even know why anyone would think in those terms.
I don't know if that fits into what you're talking about, but is it really an Eastern Europe thing to think you're the best? I've seen it a few times, I don't know where it comes from, and I don't want to stereotype based on confirmation bias.
A few years ago, I worked with a developer from Eastern Europe who told me he believed the developers in the European part of the company were better than those in the US part of the company.
I found this to be a bizarre statement (and not true) and I don't even know why anyone would think in those terms.
I don't know if that fits into what you're talking about, but is it really an Eastern Europe thing to think you're the best? I've seen it a few times, I don't know where it comes from, and I don't want to stereotype based on confirmation bias.
> I've found that Eastern European developers generally believe they are the best (even when they aren't).
Eastern Europe is an extremely ambiguous category, unless from where you sit the cultures of Estonia, Poland, Russia, and Armenia seem to produce similar junior developers. I suspect for US it translates to "post-Soviet countries", which is quite an outdated viewpoint.
https://en.wikipedia.org/wiki/Eastern_Europe
Eastern Europe is an extremely ambiguous category, unless from where you sit the cultures of Estonia, Poland, Russia, and Armenia seem to produce similar junior developers. I suspect for US it translates to "post-Soviet countries", which is quite an outdated viewpoint.
https://en.wikipedia.org/wiki/Eastern_Europe
> For example working with some (not all) developers in Asia, its culturally negative to admit you don't know something.
If this is true, and junior devs in Asia are all wandering around unwilling to ask questions to understand things, then they must have come up with a different approach culturally to learn and grow quickly.
Are there any Asia-based developers here that could speak to the main approach by which junior developers become senior?
If this is true, and junior devs in Asia are all wandering around unwilling to ask questions to understand things, then they must have come up with a different approach culturally to learn and grow quickly.
Are there any Asia-based developers here that could speak to the main approach by which junior developers become senior?
I’m from Southeast Asia and I have been a team lead before. There’s no issues for junior devs asking questions, the challenge is that they will hesitate to ask or clarify questions with foreigners.
I myself do not subscribe to this stereotype, I have seen both extremes in junior dev. Some ask nothing but figure it out themselves, some ask too much and figure out nothing, some did both, some didn't and failed miserably. Some exhibit a mixture of these 4 quadrants.
For me, I'm resourceful and have ways to learn how things work myself, either by googling or asking peers. If I'm asked a question that I don't know about at point blank, I usually follow this template
1. Silent thinking for 2-3 seconds
2. Talk about something closely relevant that I actually know about
3. Concludes with "that being said, let me do some digging and get back to you"
This demonstrates that I understand the question, I know something relevant, and that I'm willing find out things that idk about. Especially if you're higher up the ladder, saying you don't know requires tact, I believe this is not specific to Asia. There's a fine line between this and a bullshitter; a bs-er simply drifts away from the topic and never comes back nor willing to find things out.
That being said, I adjust my strategy according to the culture of the company that I'm working in.
For me, I'm resourceful and have ways to learn how things work myself, either by googling or asking peers. If I'm asked a question that I don't know about at point blank, I usually follow this template
1. Silent thinking for 2-3 seconds
2. Talk about something closely relevant that I actually know about
3. Concludes with "that being said, let me do some digging and get back to you"
This demonstrates that I understand the question, I know something relevant, and that I'm willing find out things that idk about. Especially if you're higher up the ladder, saying you don't know requires tact, I believe this is not specific to Asia. There's a fine line between this and a bullshitter; a bs-er simply drifts away from the topic and never comes back nor willing to find things out.
That being said, I adjust my strategy according to the culture of the company that I'm working in.
Sure that’s why I said “not all”.
But in general, for the most part, it’s a “thing”.
Let me repeat, it’s not a negative at all since it’s mostly cultural.
The negative only happens when you don’t understand and observe it.
But in general, for the most part, it’s a “thing”.
Let me repeat, it’s not a negative at all since it’s mostly cultural.
The negative only happens when you don’t understand and observe it.
As someone from Southeast Asia I agree with your first point. Being “shy” with foreigners is still a thing here. You can really tell an experience dev here if he’s very comfortable speaking with foreigners.
In my 12 yoe it still surprises me that majority of the devs I know doesn’t communicate outside with other developers internationally like in SO chat, Reddit or here.
In my 12 yoe it still surprises me that majority of the devs I know doesn’t communicate outside with other developers internationally like in SO chat, Reddit or here.
Having worked with devs from Asia, Europe and the US, I can relate to this. And yes, devs from Eastern European countries are really hard to work with due this attitude.
What are some of the successful methods you mentioned in your first point re: different cultural values?
It’s just understand the cultural part of it.
Once you do, you don’t see it as a negative and you can kind of observe the signs.
Example, I will follow up on the developer and a task a few hours in. This will let me know if they are on point.
It’s better than waiting days and realizing the task is completely different than what you wanted.
Also - this is a big deal, you need to be self aware and ask yourself if you are explaining what you want in a clear way.
I’ve become better at explaining myself because of working with developers from different cultures to mine.
Once you do, you don’t see it as a negative and you can kind of observe the signs.
Example, I will follow up on the developer and a task a few hours in. This will let me know if they are on point.
It’s better than waiting days and realizing the task is completely different than what you wanted.
Also - this is a big deal, you need to be self aware and ask yourself if you are explaining what you want in a clear way.
I’ve become better at explaining myself because of working with developers from different cultures to mine.
Don't jump on me at 9 AM with a list of questions you have from the night before - I am going through e-mails and instant messages at that time. Wait half an hour, unless it is an emergency.
Like most people, I eat lunch at some point between noon and 1 PM. That's why my calendar is open, yours is as well, as are most people's. This is a bad time to start peppering me with questions.
Also, don't struggle on something all day and then at 4:45PM tell me you haven't made any progress and ask for help. Have this realization at 4 PM, or better yet 3:30PM or even 3:00PM. Sometimes a quick look by me at 3 PM can get you on the right path again.