You will ask many, many questions
letterstoanewdeveloper.com
letterstoanewdeveloper.com
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.
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.
* 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.
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 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.
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.
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.)
It works wonders, and discussing actual code makes it easier for most people than discussing abstract concepts.
This kind of advice really goes overboard and harms people who would listen to it.
The suggestion that you should solve problems on your own is far more harmful. Software development is a team sport.
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.
My current job, I'm three years in, still learning new things that are adjacent to my job.
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.
I did. 90% of their questions were 1 Google search and 1 stack overflow click away.
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.
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.
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.
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?
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.
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...
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?
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.
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.
- 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.
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.
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.
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.
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.