7 ms·

A thread for Junior Developers/Engineers

99 points by yvonnick 8y ago

drewmassey 8y ago
“Get to know your problem so well that fixing it by writing code is a last resort” I love this stance.
Yhippa 8y ago
> Get to know your problem so well that fixing the problem by writing code is the last resort > This means having to problem-solve with business people and doctors, for example. > It might mean having to learn more skills: marketing, product design, business planning, etc. I like this point. In an enterprise there are multiple ways to solve a problem without code.
fisensee 8y ago
> Maybe every morning they take the first 30 minutes of their day to tell you about what movie they watched last night? E-v-e-r-y-d-a-y. Funnily enough I always think these are some of the best 30 minutes of my day. Certainly beats having to talk about your favorite design pattern first thing in the morning.
- i_cant_speel 8y ago
  My only gripe with this is that I like to get in early in the mornings to get work done before everyone else comes in and the distractions start. There is one other person that comes in as early as I do, and he will occasionally come over and start a conversation and just won't stop. It doesn't matter if I'm wearing headphones or anything. He's a nice guy and I will sometimes go along with it, but other mornings when I have a lot to do it drives me crazy.
  - pistoriusp 8y ago
    You owe it to them, and yourself, to just tell them that you're really busy right now and that you'll love to chat... later.
    - commandlinefan 8y ago
      "So it says here in your performance review that your peers have consistently rated you as 'not being a team player'... what do you think we can do to improve upon this in the next evaluation period?"
- dtech 8y ago
  Yes, unless you're someone who wants to do something at that point in time. I have a co-worker who gets fidgety for beers every Thursday around 15:00. He starts walking around, loudly talking with anyone and telling stories. That's super-annoying for me because 14:00-17:00 is the time I'm most productive. Woes of an open office ¯\_(ツ)_/¯
  - loco5niner 8y ago
    Same here. I used to get in at 6. 6-7 was the most productive hour of the day because general staff got in at 7. But my co-worker always wanted to talk right when we got in. Woes of the open office
- wccrawford 8y ago
  We actually have an informal meeting in the mornings here. Nobody is required to attend or pay attention, and we generally talk about things in our lives like TV/games/etc or what we did over the weekend, and then move into what we're working on. Management occasionally suggests that maybe the meetings are a bit too long, but I think everyone is generally okay with saying they need the meeting to end because they want/need to work on something. I'm now wondering if I need to make it a little more clear that that's a thing they can say without it causing an issue.
sarcasmic 8y ago
1. Communicating clearly in 'business language' is essential when the junior developer interfaces directly -- not through an intermediary -- with business people and stakeholders. This tends to happen in heavily siloed BigCos, especially in places where IT is just a business unit among many, much more so than in SV or startups. But it's also a skill that one rarely has an opportunity to use in isolation, away from the pressures of estimation, project management, of implicit requirements-gathering by listening to business units segue to different business problem, and sometimes of fudging and obfuscation and make-believe falsehoods to soften the impact of reality. These are complex dynamics usually played at the senior team lead level. Most team leads know this, and don't subject junior engineers to this game with no help. 2. These sorts of high-level expectations tend to get peddled around a lot, not the least bit because it's both noncontroversial advice and a desirable baseline, but they aren't even always necessary. Often, the systems one will work on already exist, they already don't conform to an idealized model because of a series of fixes and mistakes made under pressure. These points are a stand-in for saying you should design and code in a way that future maintainers can make sense of what was written. Sometimes that's using patterns and strategies that are well known, instead of a contrived variation. Sometimes that's staying true to the existing design of the product and the codebase, because tacked-on parts in a different style will increase complexity of the whole. 3. Interfacing in the design and mechanical sense, and achieving that design consensus using interpersonal relations are really two separate skills, and once again it's reasonable to expect that consensus to be set not solely by junior staff between different business units. After all, interfaces and system boundaries ought to have business significance -- not only because of the implications of Conway's law, but also because interfaces and their outputs are often the only orgwide-visible products of the business unit. They must stand up to, or meet the challenge of future pressures such as planned re-use and enhancements, some of which will conflict with the intentions behind the original design.
balls187 8y ago
"Coding is the easy part" Yes...but, only for really good engineers.
- wccrawford 8y ago
  I disagree. For bad engineers, coding is still easier than figuring out the solution to the problem, even if they find coding really hard.
  - daveFNbuck 8y ago
    It's usually easy to figure out a bad or incomplete solution that is difficult to code.
    - wccrawford 8y ago
      Are you saying that it's okay for junior developers to develop non-acceptable solutions? Because it's not okay in my book. Figuring out how to design half of a system isn't anything. Anyone can do that. Non-programmers do that all the time. Engineering a solution means the whole thing, not just the easy parts of it, just like coding the solution means coding the whole things, not just the easy parts of it.
      - daveFNbuck 8y ago
        I'm saying that inexperience and bad design add to the difficulty of coding.
      - daveFNbuck 8y ago
        I'm not saying it's ok, just that people often have more trouble with coding than finding a solution because bad solutions can be easy to find but hard to code.
- piotrkubisa 8y ago
  I also disagree, coding is the easy part. When you are junior not everyone requires from you to be know-it-all person nor providing super-good quality code, especially in your first months of journey in the company codebase. However, almost anyone wants to notice a "fresh air" and a person who shares his/her commitment in various form starting from the day one. Edit: Hey, it is easy to implement code having bugs (shortly: implement bugs) and do many fixes further. It is hard to understand the problem and write code once, which won't need any bugfix. Think about the Apollo-11 code [0] - one tiny bug and astronauts might be dead. [0]: https://github.com/chrislgarry/Apollo-11 https://github.com/chrislgarry/Apollo-11
CodeSheikh 8y ago
If requirements are not clear, stop coding and start asking questions. If your company track stories in JIRA then tag PM or anyone from the business who can help you clarify the requirements. From my experience, PMs are not sure what the exact requirements are. So asking them questions open up a channel of back-and-forth discussion.
- walshemj 8y ago
  "If your company track stories in JIRA" I think that's your problem right there. If your building a product or major feature and not a bugfix you should have a proper version controlled design document or documents to work from and also a lead or architect to get guidance from.
  - giancarlostoro 8y ago
    Right after Excel, JIRA is one of the most abused tools out there. I wish specs were in version control, but we too use that "ticket per feature" workflow at my job. I rather a Confluence page outlining what we want.
mathgladiator 8y ago
I am planning to write a site that helps people understand the career beyond the code. I have five sections planned. 1. Not Yet Engineer 2. Junior Engineer 3. Practitioner Engineer 4. Senior Engineer 5. Principal Engineer I intend to index my thoughts as a philosophy guide and playbook for situations since that is what I tend to focus on in my one on ones with the people that I mentor. It's funny that as I have gotten older, I focus less on the 'what' and 'how' and focus on people growth, and now my primary export is enabling people to become effective senior engineers.
- cweagans 8y ago
  I would be super interested in collaborating on this. Are you thinking that it would be written in the open + allow contributions from others?
  - mathgladiator 8y ago
    I honestly don't know, and I am considering inventing a platform so that I can express how I get feedback. I am definitely interested in feedback, but I also want to create an income stream from it.
- walshemj 8y ago
  You know that most companies don't have such nice technical hierarchies. When I worked for BT back in the day there where effectively two grades for non management "professional staff" going from mpg1 to mpg2 was brutal approximately 20-30 in the SE division (50k FTE) every 18 months or so.
  - mathgladiator 8y ago
    True, but that doesn't mean the behaviors are not mutually exclusive. For instance, there is a time in your life before you know how to code and there is a time where you think you know how to code and then have to interview. I call this "Not Yet Engineer". There is then a time when you think you know how to code, but you lack discipline to execute within a team framework and a business context. I call this the "Junior Engineer" phase. After Junior Engineer, you are useful and can build things. Once you have discipline and have knowledge, then are a "Practitioner Engineer". This, for many people, is a terminal state and some companies call this senior engineer. However, I have seen many people go from inflated titles to Software Engineer at Amazon. Beyond Practitioner Engineer, the core aspect of being a "Senior Engineer" is the ability to lead one or two teams to build. Principal Engineers then talk at an organization level and think of things beyond two teams. The focus here is on strategy rather than day to day execution. Sadly, most companies don't understand the need for a parallel power structure to compete with management.
giancarlostoro 8y ago
On that note what are good books to develop communication skills? Are there any that are specifically targeting tech business communication as well?
yakshaving_jgt 8y ago
Generally I agree with this thread of advice, but I’m a little fed up with people constantly asserting or implying that coding is the easy part, and culture is the super hard part. Get a grip. Coding is a challenge for junior developers. I see nothing constructive in spreading this idea. Not only is it nonsense, it seems to further the stereotype that programmers are all academically smart and socially incompetent. Edit: Please see Camille Fournier’s earlier take on this, as she says it better than me: https://mobile.twitter.com/skamille/status/1004731136562561025 https://mobile.twitter.com/skamille/status/10047311365625610...
- oarabbus_ 8y ago
  It also furthers the notion that "coding is easy" and if it doesn't come easy to you then you simply aren't a good programmer and will never be one.
  - mesozoic 8y ago
    I think this really means that while coding is hard it is the fun thing, it is a hard thing that is fun to do and easily can lead to flow states which we interpret as "fun". That's great, as you advance in your career though it turns out many times coding isn't the most valuable thing you can be doing with your time but rather things like explaining, teaching, guiding. Things that aren't so easily defined as fun. So coding is easy not as in the simple vs difficult way but in the "easy going" way.
- rurp 8y ago
  I definitely agree with this and want to add that coding _well_ is difficult for people of all experience levels, it's not something developers get nailed down their first couple years of working and then have forever. But producing excellent code that is easy to work with can help with the culture part. I've worked with very knowledgeable and experienced engineers that could crank out plenty of buggy and convoluted code that caused other people headaches. Writing clean and well designed code makes coworkers lives easier.
- RyanOD 8y ago
  I would argue "hard" is relative and every job has aspects that are "hard" or "easy" depending on the individual. While I appreciate this thread seed, to point to either set and label it seems arbitrary.
Zero1X 8y ago
Don't think I am trying to diminish the importance of this post but Gerald Weinberg has talked about all these concepts a long time ago in his books. Sadlly, I discovered him (through DHH book recommendations) at a much later stage in my career.Gerald Weinberg should be a required reading to all software engineers.
InclinedPlane 8y ago
My one major criticism of this advice is that it significantly downplays the importance of communicating clearly among technical people. It's tempting to think this is "easy" but I've seen countless examples among top developers at all sorts of prestigious corporations proving that it's anything but. Some common mistakes I see people make: Excess aggression, ego, and emotion. Check your ego, disconnect your self from instances of your work whether it's your code, your proposals, or your ideas. And be kind to others in criticisms, don't criticize (and especially not denigrate) other people criticize their code or their actions. Instead of saying "this is bad, why would you write this garbage?" say "here's a way to do it that I think is better for X/Y/Z reasons". The work is just the work, it's a collaborative effort to improve it. There should never be shouting or hurt emotions when hashing out designs or doing code reviews, work towards that goal. Insufficient context. Make a habit of regularly summing up context in ongoing discussions and injecting it into the thread (email, IM, meeting, what-have-you). Do this explicitly when looping in new people to a discussion. The worst thing is to be looped into some long email thread and having to follow through the winding and convoluted discussion just to acquire context that could have been summed up by someone in the know with a few sentences. Even worse is when significant amounts of context are missing from the conversation because they happened in person or in other media or happened in previous discussions. Unspoken assumptions. Much like summing up context stating your assumptions is critical to communicating effectively because it's so easy to assume that your little bubble of understanding is universal but it rarely is. And unspoken assumptions are one of the easiest ways for two people (or orgs) to be party to the same discussion and come out of it with completely different conclusions about what will happen next. And on that note, be clear when you're asking anyone anything, whether it's a question or a deliverable. Address them directly, use a question mark. You'd be shocked how often people fail at this sort of thing, especially in large discussion threads. Don't just leave pseudo-questions dangling, waiting for whoever is responsible to pick it up. Be direct, if you don't know who the responsible party should be, ask, maybe nobody knows and it needs to be determined/negotiated. If you know then make sure. And, of course, be polite. Not going on the evidence. A close cousin to riding on unspoken assumptions, especially problematic in troubleshooting and debugging scenarios. Definitely a common mistake I see all the time in CS graduates (who, ironically, aren't very good scientists). Use the scientific method. Don't just make assumptions and tell stories that are convenient or kinda sorta make sense to you. Don't just "satisfice" by resting on the first semi-plausible answer you land on. Dig in, find the truth. Start with a hypothesis (or several), acquire evidence, figure out if you can for sure confirm or falsify your hypothesis (and competing ones) through the evidence. Keep coming up with other things to check that could provide additional evidence one way or the other, and competing hypotheses as well. Keep going until you have a rock solid "case" and can prove your theory. I have seen even very experienced developers screw this up countless times. They come up with some vaguely plausible cause for a problem and then spend way too much time operating as though it's true, without validating it first. And then they waste a ton of time and effort trying to "fix" the wrong thing. Just as often devs will put in a hacky workaround for a defect which just papers over the underlying problem. Pursue defects to their root cause, file bugs in your tracker to keep track of that information and put fixing it on the radar of the team/org/management so at least they are making a conscious choice if they choose not to fix it.
Envision_Envi 8y ago
It's difficult to handle by junior developer itself.

99 points by yvonnick 8y ago

“Get to know your problem so well that fixing it by writing code is a last resort” I love this stance.

> Get to know your problem so well that fixing the problem by writing code is the last resort > This means having to problem-solve with business people and doctors, for example. > It might mean having to learn more skills: marketing, product design, business planning, etc. I like this point. In an enterprise there are multiple ways to solve a problem without code.

fisensee 8y ago

> Maybe every morning they take the first 30 minutes of their day to tell you about what movie they watched last night? E-v-e-r-y-d-a-y. Funnily enough I always think these are some of the best 30 minutes of my day. Certainly beats having to talk about your favorite design pattern first thing in the morning.

i_cant_speel 8y ago
My only gripe with this is that I like to get in early in the mornings to get work done before everyone else comes in and the distractions start. There is one other person that comes in as early as I do, and he will occasionally come over and start a conversation and just won't stop. It doesn't matter if I'm wearing headphones or anything. He's a nice guy and I will sometimes go along with it, but other mornings when I have a lot to do it drives me crazy.
- pistoriusp 8y ago
  You owe it to them, and yourself, to just tell them that you're really busy right now and that you'll love to chat... later.
  - commandlinefan 8y ago
    "So it says here in your performance review that your peers have consistently rated you as 'not being a team player'... what do you think we can do to improve upon this in the next evaluation period?"
dtech 8y ago
Yes, unless you're someone who wants to do something at that point in time. I have a co-worker who gets fidgety for beers every Thursday around 15:00. He starts walking around, loudly talking with anyone and telling stories. That's super-annoying for me because 14:00-17:00 is the time I'm most productive. Woes of an open office ¯\_(ツ)_/¯
- loco5niner 8y ago
  Same here. I used to get in at 6. 6-7 was the most productive hour of the day because general staff got in at 7. But my co-worker always wanted to talk right when we got in. Woes of the open office
wccrawford 8y ago
We actually have an informal meeting in the mornings here. Nobody is required to attend or pay attention, and we generally talk about things in our lives like TV/games/etc or what we did over the weekend, and then move into what we're working on. Management occasionally suggests that maybe the meetings are a bit too long, but I think everyone is generally okay with saying they need the meeting to end because they want/need to work on something. I'm now wondering if I need to make it a little more clear that that's a thing they can say without it causing an issue.

sarcasmic 8y ago

1. Communicating clearly in 'business language' is essential when the junior developer interfaces directly -- not through an intermediary -- with business people and stakeholders. This tends to happen in heavily siloed BigCos, especially in places where IT is just a business unit among many, much more so than in SV or startups. But it's also a skill that one rarely has an opportunity to use in isolation, away from the pressures of estimation, project management, of implicit requirements-gathering by listening to business units segue to different business problem, and sometimes of fudging and obfuscation and make-believe falsehoods to soften the impact of reality. These are complex dynamics usually played at the senior team lead level. Most team leads know this, and don't subject junior engineers to this game with no help. 2. These sorts of high-level expectations tend to get peddled around a lot, not the least bit because it's both noncontroversial advice and a desirable baseline, but they aren't even always necessary. Often, the systems one will work on already exist, they already don't conform to an idealized model because of a series of fixes and mistakes made under pressure. These points are a stand-in for saying you should design and code in a way that future maintainers can make sense of what was written. Sometimes that's using patterns and strategies that are well known, instead of a contrived variation. Sometimes that's staying true to the existing design of the product and the codebase, because tacked-on parts in a different style will increase complexity of the whole. 3. Interfacing in the design and mechanical sense, and achieving that design consensus using interpersonal relations are really two separate skills, and once again it's reasonable to expect that consensus to be set not solely by junior staff between different business units. After all, interfaces and system boundaries ought to have business significance -- not only because of the implications of Conway's law, but also because interfaces and their outputs are often the only orgwide-visible products of the business unit. They must stand up to, or meet the challenge of future pressures such as planned re-use and enhancements, some of which will conflict with the intentions behind the original design.

balls187 8y ago

"Coding is the easy part" Yes...but, only for really good engineers.

wccrawford 8y ago
I disagree. For bad engineers, coding is still easier than figuring out the solution to the problem, even if they find coding really hard.
- daveFNbuck 8y ago
  It's usually easy to figure out a bad or incomplete solution that is difficult to code.
  - wccrawford 8y ago
    Are you saying that it's okay for junior developers to develop non-acceptable solutions? Because it's not okay in my book. Figuring out how to design half of a system isn't anything. Anyone can do that. Non-programmers do that all the time. Engineering a solution means the whole thing, not just the easy parts of it, just like coding the solution means coding the whole things, not just the easy parts of it.
    - daveFNbuck 8y ago
      I'm saying that inexperience and bad design add to the difficulty of coding.
    - daveFNbuck 8y ago
      I'm not saying it's ok, just that people often have more trouble with coding than finding a solution because bad solutions can be easy to find but hard to code.
piotrkubisa 8y ago
I also disagree, coding is the easy part. When you are junior not everyone requires from you to be know-it-all person nor providing super-good quality code, especially in your first months of journey in the company codebase. However, almost anyone wants to notice a "fresh air" and a person who shares his/her commitment in various form starting from the day one. Edit: Hey, it is easy to implement code having bugs (shortly: implement bugs) and do many fixes further. It is hard to understand the problem and write code once, which won't need any bugfix. Think about the Apollo-11 code [0] - one tiny bug and astronauts might be dead. [0]: https://github.com/chrislgarry/Apollo-11 https://github.com/chrislgarry/Apollo-11

CodeSheikh 8y ago

If requirements are not clear, stop coding and start asking questions. If your company track stories in JIRA then tag PM or anyone from the business who can help you clarify the requirements. From my experience, PMs are not sure what the exact requirements are. So asking them questions open up a channel of back-and-forth discussion.

walshemj 8y ago
"If your company track stories in JIRA" I think that's your problem right there. If your building a product or major feature and not a bugfix you should have a proper version controlled design document or documents to work from and also a lead or architect to get guidance from.
- giancarlostoro 8y ago
  Right after Excel, JIRA is one of the most abused tools out there. I wish specs were in version control, but we too use that "ticket per feature" workflow at my job. I rather a Confluence page outlining what we want.

mathgladiator 8y ago

I am planning to write a site that helps people understand the career beyond the code. I have five sections planned. 1. Not Yet Engineer 2. Junior Engineer 3. Practitioner Engineer 4. Senior Engineer 5. Principal Engineer I intend to index my thoughts as a philosophy guide and playbook for situations since that is what I tend to focus on in my one on ones with the people that I mentor. It's funny that as I have gotten older, I focus less on the 'what' and 'how' and focus on people growth, and now my primary export is enabling people to become effective senior engineers.

cweagans 8y ago
I would be super interested in collaborating on this. Are you thinking that it would be written in the open + allow contributions from others?
- mathgladiator 8y ago
  I honestly don't know, and I am considering inventing a platform so that I can express how I get feedback. I am definitely interested in feedback, but I also want to create an income stream from it.
walshemj 8y ago
You know that most companies don't have such nice technical hierarchies. When I worked for BT back in the day there where effectively two grades for non management "professional staff" going from mpg1 to mpg2 was brutal approximately 20-30 in the SE division (50k FTE) every 18 months or so.
- mathgladiator 8y ago
  True, but that doesn't mean the behaviors are not mutually exclusive. For instance, there is a time in your life before you know how to code and there is a time where you think you know how to code and then have to interview. I call this "Not Yet Engineer". There is then a time when you think you know how to code, but you lack discipline to execute within a team framework and a business context. I call this the "Junior Engineer" phase. After Junior Engineer, you are useful and can build things. Once you have discipline and have knowledge, then are a "Practitioner Engineer". This, for many people, is a terminal state and some companies call this senior engineer. However, I have seen many people go from inflated titles to Software Engineer at Amazon. Beyond Practitioner Engineer, the core aspect of being a "Senior Engineer" is the ability to lead one or two teams to build. Principal Engineers then talk at an organization level and think of things beyond two teams. The focus here is on strategy rather than day to day execution. Sadly, most companies don't understand the need for a parallel power structure to compete with management.

giancarlostoro 8y ago

On that note what are good books to develop communication skills? Are there any that are specifically targeting tech business communication as well?

yakshaving_jgt 8y ago

Generally I agree with this thread of advice, but I’m a little fed up with people constantly asserting or implying that coding is the easy part, and culture is the super hard part. Get a grip. Coding is a challenge for junior developers. I see nothing constructive in spreading this idea. Not only is it nonsense, it seems to further the stereotype that programmers are all academically smart and socially incompetent. Edit: Please see Camille Fournier’s earlier take on this, as she says it better than me: https://mobile.twitter.com/skamille/status/1004731136562561025 https://mobile.twitter.com/skamille/status/10047311365625610...

oarabbus_ 8y ago
It also furthers the notion that "coding is easy" and if it doesn't come easy to you then you simply aren't a good programmer and will never be one.
- mesozoic 8y ago
  I think this really means that while coding is hard it is the fun thing, it is a hard thing that is fun to do and easily can lead to flow states which we interpret as "fun". That's great, as you advance in your career though it turns out many times coding isn't the most valuable thing you can be doing with your time but rather things like explaining, teaching, guiding. Things that aren't so easily defined as fun. So coding is easy not as in the simple vs difficult way but in the "easy going" way.
rurp 8y ago
I definitely agree with this and want to add that coding _well_ is difficult for people of all experience levels, it's not something developers get nailed down their first couple years of working and then have forever. But producing excellent code that is easy to work with can help with the culture part. I've worked with very knowledgeable and experienced engineers that could crank out plenty of buggy and convoluted code that caused other people headaches. Writing clean and well designed code makes coworkers lives easier.
RyanOD 8y ago
I would argue "hard" is relative and every job has aspects that are "hard" or "easy" depending on the individual. While I appreciate this thread seed, to point to either set and label it seems arbitrary.

Zero1X 8y ago

Don't think I am trying to diminish the importance of this post but Gerald Weinberg has talked about all these concepts a long time ago in his books. Sadlly, I discovered him (through DHH book recommendations) at a much later stage in my career.Gerald Weinberg should be a required reading to all software engineers.

InclinedPlane 8y ago

My one major criticism of this advice is that it significantly downplays the importance of communicating clearly among technical people. It's tempting to think this is "easy" but I've seen countless examples among top developers at all sorts of prestigious corporations proving that it's anything but. Some common mistakes I see people make: Excess aggression, ego, and emotion. Check your ego, disconnect your self from instances of your work whether it's your code, your proposals, or your ideas. And be kind to others in criticisms, don't criticize (and especially not denigrate) other people criticize their code or their actions. Instead of saying "this is bad, why would you write this garbage?" say "here's a way to do it that I think is better for X/Y/Z reasons". The work is just the work, it's a collaborative effort to improve it. There should never be shouting or hurt emotions when hashing out designs or doing code reviews, work towards that goal. Insufficient context. Make a habit of regularly summing up context in ongoing discussions and injecting it into the thread (email, IM, meeting, what-have-you). Do this explicitly when looping in new people to a discussion. The worst thing is to be looped into some long email thread and having to follow through the winding and convoluted discussion just to acquire context that could have been summed up by someone in the know with a few sentences. Even worse is when significant amounts of context are missing from the conversation because they happened in person or in other media or happened in previous discussions. Unspoken assumptions. Much like summing up context stating your assumptions is critical to communicating effectively because it's so easy to assume that your little bubble of understanding is universal but it rarely is. And unspoken assumptions are one of the easiest ways for two people (or orgs) to be party to the same discussion and come out of it with completely different conclusions about what will happen next. And on that note, be clear when you're asking anyone anything, whether it's a question or a deliverable. Address them directly, use a question mark. You'd be shocked how often people fail at this sort of thing, especially in large discussion threads. Don't just leave pseudo-questions dangling, waiting for whoever is responsible to pick it up. Be direct, if you don't know who the responsible party should be, ask, maybe nobody knows and it needs to be determined/negotiated. If you know then make sure. And, of course, be polite. Not going on the evidence. A close cousin to riding on unspoken assumptions, especially problematic in troubleshooting and debugging scenarios. Definitely a common mistake I see all the time in CS graduates (who, ironically, aren't very good scientists). Use the scientific method. Don't just make assumptions and tell stories that are convenient or kinda sorta make sense to you. Don't just "satisfice" by resting on the first semi-plausible answer you land on. Dig in, find the truth. Start with a hypothesis (or several), acquire evidence, figure out if you can for sure confirm or falsify your hypothesis (and competing ones) through the evidence. Keep coming up with other things to check that could provide additional evidence one way or the other, and competing hypotheses as well. Keep going until you have a rock solid "case" and can prove your theory. I have seen even very experienced developers screw this up countless times. They come up with some vaguely plausible cause for a problem and then spend way too much time operating as though it's true, without validating it first. And then they waste a ton of time and effort trying to "fix" the wrong thing. Just as often devs will put in a hacky workaround for a defect which just papers over the underlying problem. Pursue defects to their root cause, file bugs in your tracker to keep track of that information and put fixing it on the radar of the team/org/management so at least they are making a conscious choice if they choose not to fix it.

Envision_Envi 8y ago

It's difficult to handle by junior developer itself.