7 ms·

I always found this interesting about my junior developers. When I teach a new concept, I can instinctively tell who will listen, apply it and be able to move

I always found this interesting about my junior developers. When I teach a new concept, I can instinctively tell who will listen, apply it and be able to move on to tougher concepts while understanding that some of them will be hard headed and will have to be beaten into submission. One day, I got fed up with one of them (he kept trying to parse JSON by splitting the string in Java), and told him I would honestly use GSON to parse it because I'm lazy. I could see it click in his mind, as he realized writing a small JSON schema in Java was easier than his convoluted 12-step if statement chain (he was performing the string splitting based on the URL he was doing REST requests against). Now I call it the 'laziness as teaching' tool. 1) Admit you're doing it because you're lazy 2) List the set of items that need to be done in the new lazy approach 3) Contrast it against the previous method 4) Watch it click as they realize their way is so much extra work.

zeta0134 7y ago
Why do I use JSON? No, it's probably not the best tool for the job. But it's quite adequate, and I don't have to write my own parser. That every other language on the planet can now also interface with my API with minimal fuss is just an added bonus. :)
hinkley 7y ago
When I'm feeling sardonic I will call it 'being lazy' but at other times I will describe it as "because I have better shit to do."
pm90 7y ago
Well, part of the problem is the intrinsic desire for the person to prove themselves to you by doing a great job. Sometimes it’s more useful to let them try for a bit, before showing how your solution might be better. Letting juniors experiment the best design by failing is sometimes an effective strategy. And if they do succeed or produce a better solution, awesome. That is a lesson that you can learn from (technology changes very quickly).
taneq 7y ago
Laziness is, after all, one of the core virtues of a programmer (along with impatience and hubris.)
- soup10 7y ago
  A certain amount of laziness really is an important skill to have as a programmer, the busy bee will do lots over-engineering over-architecting and wheel reinventing. Where the lazy guy will go out of their way to find and use libraries and tools that save them effort and get the job done and have way less bloated code. On the other hand things like not being diligent about fixing bugs can be a problem though.
tempguy9999 7y ago
> 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.
silveroriole 7y ago
Question is, what do you do with the juniors who never get it? Those for whom mistakes/inefficiency aren’t just “mistakes” but are their normal mode of operation? I’ve had juniors who I did this “well, I’d be lazy and just use a library/script” routine on, and they essentially ignored me and went straight back to what they were doing. Either they were afraid of admitting they’d gotten it ‘wrong’ and were unwilling to abandon that method they’d personally thought of, or they genuinely didn’t even agree that they were struggling in the first place - in some weird way they must have ENJOYED struggling and thought it meant they were learning or solving something hard.
- theossuary 7y ago
  > in some weird way they must have ENJOYED struggling and thought it meant they were learning or solving something hard I'm not sure why you're incredulous about this? If you're struggling to write your own JSON parser, you are learning something new by doing something hard. Maybe you're not learning a lot (if you're just brute-forcing it), but you're still learning. Being in flow means you aren't learning, it isn't deliberate practice. If somebody was wasting a lot of time rewriting a library instead of using it, it might be time to have a discussion on learning vs delivering value. I think 20%-30% is the sweet spot of learning vs producing.
  - silveroriole 7y ago
    I think enjoying the struggle will lead you wrong more often than not. I normally find that if I’m really struggling, it doesn’t mean I’m learning, it means I’m missing some information and I need to seek guidance. I’ve always learned more from looking at a successful existing implementation than trying to brute force my own solution (though it’s fun/useful to have a pop at something on your own first, of chorse). Sure, you need some tenacity and concentration, but I don’t understand people who will happily and repeatedly bash their head against a wall for hours without ever checking whether there’s a way around the wall!
- WrtCdEvrydy 7y ago
  > what do you do with the juniors who never get it? It's kinda weird, because I only get the juniors that are on the fast track for promotion. I'm just supposed to fill in any holes on their knowledge sets for React, NodeJS, and some of the legacy applications in house and pass them along. They'll usually only spend like 3-4 months with me. Someone who isn't learning gets sent back to the general junior developer pool for a bit longer.
barbecue_sauce 7y ago
The idea that using a library to accomplish something essential but mundane is "lazy" is weird. If your job is to transport pallets of widgets from one place to another and you elect to use a truck that someone else has manufactured rather than building your own, that's expected behavior.
- crispyambulance 7y ago
  > ...elect to use a truck that someone else has manufactured rather than building your own, that's expected behavior. To stretch the analogy a little further, if that "truck" happens to be an 18-wheeler with some crazy gearbox you've never operated it's quite normal to, instead, make several trips with your own wheelbarrow which you know you can handle. That, in many cases, might be easier than using the 18-wheeler without preparation/training.
stcredzero 7y ago
I divide my officers into four groups. There are clever, diligent, stupid, and lazy officers. Usually two characteristics are combined. Some are clever and diligent -- their place is the General Staff. The next lot are stupid and lazy -- they make up 90 percent of every army and are suited to routine duties. Anyone who is both clever and lazy is qualified for the highest leadership duties, because he possesses the intellectual clarity and the composure necessary for difficult decisions. One must beware of anyone who is stupid and diligent -- he must not be entrusted with any responsibility because he will always cause only mischief. EDIT: I misread and thought he was a supporter of the regime, but the source is not a villain as I thought before. In any case, I think there is some wisdom in this quote. https://en.wikiquote.org/wiki/Kurt_von_Hammerstein-Equord https://en.wikiquote.org/wiki/Kurt_von_Hammerstein-Equord I wonder if an RPG could be made adding these two axes to the alignment graph? (I just want to play a "Chaotic Stupid" character.)
- Apocryphon 7y ago
  “He was an ardent opponent of Hitler and the Nazi regime.” I don’t think he counts as a villain, unless you were pro-Entente.
  - stcredzero 7y ago
    Sorry, I misread that he was a supporter!

zeta0134 7y ago

Why do I use JSON? No, it's probably not the best tool for the job. But it's quite adequate, and I don't have to write my own parser. That every other language on the planet can now also interface with my API with minimal fuss is just an added bonus. :)

hinkley 7y ago

When I'm feeling sardonic I will call it 'being lazy' but at other times I will describe it as "because I have better shit to do."

pm90 7y ago

Well, part of the problem is the intrinsic desire for the person to prove themselves to you by doing a great job. Sometimes it’s more useful to let them try for a bit, before showing how your solution might be better. Letting juniors experiment the best design by failing is sometimes an effective strategy. And if they do succeed or produce a better solution, awesome. That is a lesson that you can learn from (technology changes very quickly).

taneq 7y ago

Laziness is, after all, one of the core virtues of a programmer (along with impatience and hubris.)

soup10 7y ago
A certain amount of laziness really is an important skill to have as a programmer, the busy bee will do lots over-engineering over-architecting and wheel reinventing. Where the lazy guy will go out of their way to find and use libraries and tools that save them effort and get the job done and have way less bloated code. On the other hand things like not being diligent about fixing bugs can be a problem though.

tempguy9999 7y ago

> 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.

silveroriole 7y ago

Question is, what do you do with the juniors who never get it? Those for whom mistakes/inefficiency aren’t just “mistakes” but are their normal mode of operation? I’ve had juniors who I did this “well, I’d be lazy and just use a library/script” routine on, and they essentially ignored me and went straight back to what they were doing. Either they were afraid of admitting they’d gotten it ‘wrong’ and were unwilling to abandon that method they’d personally thought of, or they genuinely didn’t even agree that they were struggling in the first place - in some weird way they must have ENJOYED struggling and thought it meant they were learning or solving something hard.

theossuary 7y ago
> in some weird way they must have ENJOYED struggling and thought it meant they were learning or solving something hard I'm not sure why you're incredulous about this? If you're struggling to write your own JSON parser, you are learning something new by doing something hard. Maybe you're not learning a lot (if you're just brute-forcing it), but you're still learning. Being in flow means you aren't learning, it isn't deliberate practice. If somebody was wasting a lot of time rewriting a library instead of using it, it might be time to have a discussion on learning vs delivering value. I think 20%-30% is the sweet spot of learning vs producing.
- silveroriole 7y ago
  I think enjoying the struggle will lead you wrong more often than not. I normally find that if I’m really struggling, it doesn’t mean I’m learning, it means I’m missing some information and I need to seek guidance. I’ve always learned more from looking at a successful existing implementation than trying to brute force my own solution (though it’s fun/useful to have a pop at something on your own first, of chorse). Sure, you need some tenacity and concentration, but I don’t understand people who will happily and repeatedly bash their head against a wall for hours without ever checking whether there’s a way around the wall!
WrtCdEvrydy 7y ago
> what do you do with the juniors who never get it? It's kinda weird, because I only get the juniors that are on the fast track for promotion. I'm just supposed to fill in any holes on their knowledge sets for React, NodeJS, and some of the legacy applications in house and pass them along. They'll usually only spend like 3-4 months with me. Someone who isn't learning gets sent back to the general junior developer pool for a bit longer.

barbecue_sauce 7y ago

The idea that using a library to accomplish something essential but mundane is "lazy" is weird. If your job is to transport pallets of widgets from one place to another and you elect to use a truck that someone else has manufactured rather than building your own, that's expected behavior.

crispyambulance 7y ago
> ...elect to use a truck that someone else has manufactured rather than building your own, that's expected behavior. To stretch the analogy a little further, if that "truck" happens to be an 18-wheeler with some crazy gearbox you've never operated it's quite normal to, instead, make several trips with your own wheelbarrow which you know you can handle. That, in many cases, might be easier than using the 18-wheeler without preparation/training.

stcredzero 7y ago

I divide my officers into four groups. There are clever, diligent, stupid, and lazy officers. Usually two characteristics are combined. Some are clever and diligent -- their place is the General Staff. The next lot are stupid and lazy -- they make up 90 percent of every army and are suited to routine duties. Anyone who is both clever and lazy is qualified for the highest leadership duties, because he possesses the intellectual clarity and the composure necessary for difficult decisions. One must beware of anyone who is stupid and diligent -- he must not be entrusted with any responsibility because he will always cause only mischief. EDIT: I misread and thought he was a supporter of the regime, but the source is not a villain as I thought before. In any case, I think there is some wisdom in this quote. https://en.wikiquote.org/wiki/Kurt_von_Hammerstein-Equord https://en.wikiquote.org/wiki/Kurt_von_Hammerstein-Equord I wonder if an RPG could be made adding these two axes to the alignment graph? (I just want to play a "Chaotic Stupid" character.)

Apocryphon 7y ago
“He was an ardent opponent of Hitler and the Nazi regime.” I don’t think he counts as a villain, unless you were pro-Entente.
- stcredzero 7y ago
  Sorry, I misread that he was a supporter!