Advice for devs who need to hear it
18 Sep 2019
This whole week has been pretty awful, major confidence issues with programming which ended up leading to a pretty big PTSD breakdown as my mental immune system was knocked so couldn't deal with triggers in the way I usually do.
Have spent a lot of time reaching out asking for advice and help from experienced developers. Here are a few snapshots of that advice from a few different people, who will remain anonymous. I'm extremely grateful for their support. Was very close to quitting the tech industry this week.
Advice to struggling devs, from experienced devs.
Trying combinations of pieces
If you think about kids learning language, they’ll experiment with the building blocks and they’ll come up with amusing constructs that are understandable but not ideal. We gently correct them, even though we understand them, because those amusing constructs have rough edges that will make things harder in the real world.
When I’m observing you performing something that I am skilled in, there are things that I can see that you can’t. I might know that two pieces don’t fit together well because I’ve tried those pieces in the past, but I couldn’t tell you in advance not to use those two pieces because I didn’t know until you started putting them together that that was a pattern you were going to try.
I’ve tried many, many thousands of combinations of pieces, and when I say “those bits don’t fit well”, I don’t mean “those bits don’t fit at all”, because we can make things fit together by adding supporting monstrosities around them (like the high rise slums). What I’m trying to get at is “there’s a Japanese joinery solution for the thing that you’re trying to force together with glue, rope, and nails; and the joinery version will be easier to change later because it’s not all gummed up with glue, rope, and nails”
And while I’d love to give you a curriculum, a specific map for how to achieve everything you want to, I’m afraid that I literally have no idea how to do that. Every single person that I have coached or mentored over the years, I have done it by watching them try to put pieces together and telling them whether I think it will work or not.
Sometimes, someone might put together two pieces in a way I’ve never seen before, and I’ll say “I have no idea if those pieces will fit, let’s explore”
But typically the learning process is “[name], will these two pieces fit together?” “No, they don’t quite match”
“OK, what about these two?” “Those are better, but you probably want to try these two”
until eventually, the other person is asking whether two pieces will fit and they’re usually getting “Yes” answers.
But there’s no test, no right answers, it’s randomly trying bits with each other until we learn which bits fit well together and which bits don’t
I can't even write simple programs
And what I’m observing with your frustrations is that when you say “I can’t even write simple programs”, it’s because you don’t know 1. which pieces are available to you, and 2. how the pieces fit together And my advice to you has been “Look around and try to find as many pieces as you can… as you find more pieces, you’ll begin to understand what pieces look like and it’ll be easier to find new ones”, and “Play with the pieces that you already have, and I’ll try and steer you away from combinations that will require you to use too much supporting infrastructure to hold them together” Reading design patterns shows you, not only some examples of small pieces, but also some examples of small pieces assembled into larger shapes, and gives some reasons about why we might want those shapes.
As you get better at recognising pieces and shapes, you also get better at recognising glue, rope, and nails. So code that used to look ok to you, you begin to see that it’s actually not that great and is not well held together. So then, you can identify bad code, not because you know what the good code will look like, but because you can see that there’s too much glue involved.
I think that’s what Ward Cunningham was getting at when he talked about clean code and elegant code. Clean code is using the absolute minimum of glue… everything that’s there needs to be there. Elegant code is the Japanese joinery… there is no need for glue, it was designed to create this shape.
Perfection is achieved, not when there’s nothing left to add, but when there’s nothing left to take away - Antoine de Saint-Exupery
My reply to the above
That was amazing. Had a little bit of a lightbulb moment last night after leaving. When I’m saying ‘I can’t program’, I’m meaning ‘I don’t think I’m able to learn how to program, therefore I can’t program’. The thing I’m more upset about is not being able to do things right away, but that the pieces that I’m playing with feel insignificant. When you said, you’re playing with a bit of pharo, and a bit of Kotlin, and a bit of design patterns, and that’s okay. I’ve been thinking, I’m doing a tiny bit of pharo, a tiny bit of kotlin and a tiny bit of design patterns, which is no where near enough, I’m not learning anything in much depth at all, but am constantly flitting. So it’s more that I’ve been feeling awful about not knowing whether what I’m doing is going to go anywhere or whether I’m boxing myself in to no progress because I’m always stuck at the start of everything I flit to
In my head it was like I’m trying to do steps that are way too small, and sometimes I can’t even do those so will never be good enough. If I cant do that how can I ever do any of the bigger stuff. Just didn’t know if the stuff I have been doing is enough or if I’m doing it wrong. Because the grains of rice are too small to notice, I won’t know until it’s too late.
An email conversation between me and a dev I sought help from
If you have time, I'd really appreciate advice when it comes to programming mindset (if not, thanks for helping me clarify thoughts in the writing of this email). My main question is right at the end of the email. The rest is a bit long-winded as a kind of explanation.
I'm completely overwhelmed with programming right now. I'm really trying to learn Test-driven development, object-oriented programming and design patterns plus a bunch of other things, but am really struggling.
To try and get better at OO, I started learning Pharo (based on Smalltalk) because I thought it would be an enabling constraint. The experiments there have helped a lot, especially the concept of messages.
More things trying out...
While I know I'm making progress, my confidence is rock-bottom. I'm starting to get a phobia reaction when it comes to building programs, it isn't fun anymore (but the lightbulb moments are).
My colleague said that it isn't possible for me to learn any of these things by myself, just like it isn't possible to learn to read by ourselves. There's a huge mindset shift.
There are a few issues with this for me. The first is that I feel like everything I know is being spoonfed to me. I think the fact that I feel that way is a result of the education system which encourages us to work alone and not 'cheat'.
The second is that everytime we sit down and pair (with either of my two colleagues), when it's my turn to take a step the feedback is usually pointing out alternatives. This is good, but it's chipping away at my self-esteem. Feedback is critical to growth, but I've gotten stuck in a loop where because I couldn't have even imagined the alternative, then I'm not good enough. Not only that, the alternatives are just as difficult to get my head around as all of these concepts, because they are informed by all of these concepts.
So to build a single, 'simple' program, it takes weeks of me trying to really understand what's going on. Every single step feels like a mountain.
I'm prepared to put the effort in, but I feel so stuck. Like I'm never going to get better and that I'm dragging my team down because I'm starting to get visibly depressed.
I have taken a week off to try and recuperate.
My main question then is, how do you learn to be okay with digging a tunnel with a plastic spoon, when someone else has to tell you where to make every dig?
Reply to my above email
Sounds like you are taking a deeply thoughtful approach to learning programming. A mistake I frequently make (in programming and [hobby], for example) is thinking too much and doing too little. All that theory jumbles up my brain so I can't act without second guessing myself eight different ways.
What I have learned is that I can't learn it all. I can't even learn most of it right away. If I learn a little, do a little, learn a little, and do a little then I maximize my learning and reduce anxiety.
Regarding your pair seeing stuff you don't see: that's what's supposed to happen.
Nobody understands everything and yet they get stuff done. The same is true of you. Cut yourself some slack. And code.
Re: better junior pair. First, not beating yourself up over not knowing everything. That's no fun to be around.
Accept that your contribution will be small at first. I started out just pointing out to my first mentor where his parentheses didn't balance. I was already useful and I was around enough to start to see the bigger patterns at work.
Another technique is to take something you worked on together and try to reproduce a small version on your own. Whether you succeed or fail doesn't matter, but where you get stuck is valuable feedback about what to learn next.
Twitter advice after sharing this post
Surround yourself with good people
There is some great advice in your article! My favorite part of the tech community is the willingness to help and your opening up to share is another incredible part of that.
Something I learned early that is a great reality check when my imposter syndrome is flaring up:
No one developer knows everything. The software world is huge, and growing every day. There is UX, Frontend, Backend, DevOps, Cloud, IoT, Imbedded Systems, and that's just to name a few topics, and huge broad ones at that.
All you can do is take it one day at a time, grow within the world you're in, commit to solving this one problem, and surround yourself with other people that feel the same way.