When senior devs don't shift their learned use of abstractions as context changes, they teach junior devs to be skeptical of abstractions.
-
-
Replying to @wycats
what is even worse is when juniors are not skeptical and start implementing abstraction for the sake of abstraction /1
1 reply 1 retweet 1 like -
Replying to @martinmcwhorter @wycats
... rather than separation of concerns, readable code or testability. /2 of 2
1 reply 1 retweet 2 likes -
Replying to @martinmcwhorter
I don't know which is "worse" but not believing in values like separation of concerns ("abstraction") is the main driver 1/
1 reply 1 retweet 2 likes -
Replying to @wycats @martinmcwhorter
of technical debt on teams with inexperienced developers, and often driven by experienced devs leaning too hard on 2/
1 reply 0 retweets 1 like -
Replying to @wycats @martinmcwhorter
out-of-date ideas about how to write reusable code that have changed from context. An extreme case of this is 3/
1 reply 0 retweets 1 like -
Replying to @wycats @martinmcwhorter
experienced devs with Java experience pushing inexperienced Ruby/JS devs to use techniques that, at minimum, should 4/
1 reply 0 retweets 3 likes -
Replying to @wycats @martinmcwhorter
be tweaked significantly before applying to Ruby/JS. Inexperienced devs begin to get skeptical of anything that smells 5/
1 reply 0 retweets 1 like
like a GOF pattern, a Java class name, etc. etc. Ultimately this leads to dysfunctional teams and 6/
-
-
Replying to @wycats @martinmcwhorter
out-of-control technical debt. 7/7
0 replies 0 retweets 3 likesThanks. Twitter will use this to make your timeline better. UndoUndo
-
Loading seems to be taking a while.
Twitter may be over capacity or experiencing a momentary hiccup. Try again or visit Twitter Status for more information.