4 ms·

> he kept trying to parse JSON by splitting the string in Java I truly do not understand the mindset that, when presented with a simple means of doing a comple

> he kept trying to parse JSON by splitting the string in Java I truly do not understand the mindset that, when presented with a simple means of doing a complex task, will do it manually[0]. If a junior dev did that in front of me I'd seriously start doubting their capability for the job. [0] The one single allowable exception is doing a crappy task manually the first time so you know how, before switching to a tool. My first parser I ever wrote I did manually rather than with flex/bison so I knew how to. After that it was tooling all the way.

rocqua 7y ago
Sometimes, the simple means of doing a complex task will 1) Bbscure the logic of solving the task. 2) Layer on extra logic of the tool. 3) Warp your thinking around the tool, causing you to miss easy optimizations. These are some reasons to not use a ready-made tool.
crispyambulance 7y ago
> If a junior dev did that in front of me I'd seriously start doubting their capability for the job. Totally wrong. Everyone has gaps in their knowledge and learned-approaches to problems. Even the most senior and experienced people have gaps, or develop gaps as things change rapidly. The junior simply did what he knew would work, and the mentor happened to know a better way. The proper, healthy response to something like that is exactly what the parent commenter did, and it ended with "a click" in the mentee's mind-- a small but noticeable step-up in the skill and knowledge of the junior. That's satisfying to both the junior and the mentor. If your response to a mistaken approach is questioning whether or not someone should even be there, well, that's pretty much an example of the sad state of the status-quo. It's how people end up making horrific software because they're too afraid of getting input from someone that can help them because they have learned, over time, that asking for help too often means a withering dismissal from someone who should have known better.
- jshowa3 7y ago
  I agree with this 100%. My last job was precisely described in your last paragraph. I loathed asking for help from a senior dev I was working with because every time I did, she made it very clear how much of a nuisance I was being. She even verbally chastised me over IM for correcting a typo in a variable in a stored procedure she wrote. Working with her was an exercise in torture and I eventually quit because my manager believed her on everything. I was also so full of self-doubt that I questioned whether I should even be a developer anymore. It screwed with my mind so much that I still have a lot of anxiety to this day.
  - tempguy9999 7y ago
    This does not relate to what I wrote. She was a dick. That does not reflect on you in any way. End of. Edit: and I'm really sorry you had to go through that.
  - crispyambulance 7y ago
    Yep, I've seen it too. Some people act that way because they experienced the same kind of abuse when they were starting out. They end up dishing out what they themselves received, perhaps believing that that's the way things are supposed to go. Others, do exactly the opposite and retroactively compensate for their mistreatment by being kind and supportive in a way they wished they had been treated.
- tempguy9999 7y ago
  > Totally wrong. Read the original post: "he KEPT TRYING to parse JSON by splitting the string in Java" This rather fits with the other bit about "beaten into submission" I have to assume from that text that he'd already been shown how to do it. If he could not understand that the easy way was easier than doing it the hard way, well pfffft. It may be there's more subtlety here than was given, I dunno.
  - crispyambulance 7y ago
    It all depends on what one means by "already been shown how to do it". Something like that could easily be misunderstood/forgotten by the trainee or glossed-over by the senior. Or maybe he was just having a bad day. Whatever the case, learning often takes some amount of repetition before mastery is achieved. Real life work is not like stackoverflow, if you have a team that's your responsibility, you can't just downvote them to oblivion. Nor can you use performance on any one incident to decide to end someone's career in that particular workplace. Sometimes people just don't measure up to expectations, that's OK, it happens, but firing should be a decision based on a history of underperformance. Questioning whether or not someone is fit to "be there" should be something that is done upon deciding to start a PIP. Otherwise, it's just eroding the confidence and motivation of the individual and the team and, in many ways, is as bad as firing that person out of spite.

rocqua 7y ago

Sometimes, the simple means of doing a complex task will 1) Bbscure the logic of solving the task. 2) Layer on extra logic of the tool. 3) Warp your thinking around the tool, causing you to miss easy optimizations. These are some reasons to not use a ready-made tool.

crispyambulance 7y ago

> If a junior dev did that in front of me I'd seriously start doubting their capability for the job. Totally wrong. Everyone has gaps in their knowledge and learned-approaches to problems. Even the most senior and experienced people have gaps, or develop gaps as things change rapidly. The junior simply did what he knew would work, and the mentor happened to know a better way. The proper, healthy response to something like that is exactly what the parent commenter did, and it ended with "a click" in the mentee's mind-- a small but noticeable step-up in the skill and knowledge of the junior. That's satisfying to both the junior and the mentor. If your response to a mistaken approach is questioning whether or not someone should even be there, well, that's pretty much an example of the sad state of the status-quo. It's how people end up making horrific software because they're too afraid of getting input from someone that can help them because they have learned, over time, that asking for help too often means a withering dismissal from someone who should have known better.

jshowa3 7y ago
I agree with this 100%. My last job was precisely described in your last paragraph. I loathed asking for help from a senior dev I was working with because every time I did, she made it very clear how much of a nuisance I was being. She even verbally chastised me over IM for correcting a typo in a variable in a stored procedure she wrote. Working with her was an exercise in torture and I eventually quit because my manager believed her on everything. I was also so full of self-doubt that I questioned whether I should even be a developer anymore. It screwed with my mind so much that I still have a lot of anxiety to this day.
- tempguy9999 7y ago
  This does not relate to what I wrote. She was a dick. That does not reflect on you in any way. End of. Edit: and I'm really sorry you had to go through that.
- crispyambulance 7y ago
  Yep, I've seen it too. Some people act that way because they experienced the same kind of abuse when they were starting out. They end up dishing out what they themselves received, perhaps believing that that's the way things are supposed to go. Others, do exactly the opposite and retroactively compensate for their mistreatment by being kind and supportive in a way they wished they had been treated.
tempguy9999 7y ago
> Totally wrong. Read the original post: "he KEPT TRYING to parse JSON by splitting the string in Java" This rather fits with the other bit about "beaten into submission" I have to assume from that text that he'd already been shown how to do it. If he could not understand that the easy way was easier than doing it the hard way, well pfffft. It may be there's more subtlety here than was given, I dunno.
- crispyambulance 7y ago
  It all depends on what one means by "already been shown how to do it". Something like that could easily be misunderstood/forgotten by the trainee or glossed-over by the senior. Or maybe he was just having a bad day. Whatever the case, learning often takes some amount of repetition before mastery is achieved. Real life work is not like stackoverflow, if you have a team that's your responsibility, you can't just downvote them to oblivion. Nor can you use performance on any one incident to decide to end someone's career in that particular workplace. Sometimes people just don't measure up to expectations, that's OK, it happens, but firing should be a decision based on a history of underperformance. Questioning whether or not someone is fit to "be there" should be something that is done upon deciding to start a PIP. Otherwise, it's just eroding the confidence and motivation of the individual and the team and, in many ways, is as bad as firing that person out of spite.