I was going to get a bit of work done for Monday. Reenpig decided that this was a bad idea. I’d left my laptop on the sofa for the time it took to refill my water glass. In that time, she crossed the length of the living room to go lie down on it.
Tag: work
How coders become architects
I don’t wanna!
I’ve been scanning old hardcopy pictures, and I came across these two. The first one was drawn on a whiteboard in the flat I used to share with Michel, corner St-Marc & Maisonneuve. It was my daily cry of desperation for almost a year, while I was slogging through my labwork. The second one is the first, original, often imitated but never exceeded, wall-o-shame-tm.
God, I don’t miss the lab…
Back to real life
Now imagine a Monday after a tiring 2-week holiday and coming back home on a Sunday and going to bed after midnight. I’m proud to have made it out of bed this morning…
Two schools of coding
That sort of links up with the recent essay on empathy for the coder.
An ode to Chiché
You must be logged in to be able to see this content.
Empathy for the coder
You read through the code. You read it again to make sure you understand what it’s doing. Your left eye starts twitching. You read the code a third time.
“WTF was wrong with the person who wrote this?”
I hate how often I react this way. It’s a quick default that’s hard to reset — immediate annoyance as if the developer or engineer responsible for writing whatever I’ve come across was scattering landmines. It’s easy to shit on the people who came before you. They’re usually not around to defend themselves or provide context. It’s much harder to calm down, and think things through. An initial reaction of “WTF?!” is entirely valid (You’re gonna feel what you’re gonna feel.), but getting stuck on the frustration and not going further is unfair to your predecessors and causes you to miss out on learning.
“How” a problem was solved/band-aided/kicked-down-the-road is usually the root of those frustrations, but the next step is thinking through the “Why” of the solution, which is often the source of useful information.
The code might be stupid, but there’s usually a reason. Maybe:
- Something stupid upstream brought its stupid with it. Alternatively, something stupid downstream needed more stupid.
- The dev/engineer was told to do it that way.
- The dev/engineer was getting pulled in 1000 different directions and needed to make a fast band-aid.
- The dev/engineer was doing the best they knew how.
- It’s actually not stupid. You just think you know more than you do.
That doesn’t rule out laziness or malice, but they’re much rarer and shouldn’t be the default assumption. When we run across goofy looking code and configs, we need to respect the constraints and context the person who wrote them faced. Note: That the person might actually be an idiot is a real, intractable constraint. How would you have fixed that?
Thinking through and learning the “whys” that caused the stupid will help you understand the context of the problem you’re currently facing. You’ll learn about not only technical pitfalls, but cultural ones as well. A lot of the stupid that shows up in code has nothing to do with the technical competence of the person who wrote it and everything to do with their manager or the company at large.
How many times has the past version of you done something stupid that harmed future you? How many times have you looked at something you made a year ago and thought “What was I thinking?” Like any skill, if you’re not embarrassed by some of the code and configs you’ve written in the past you’re 1.) an egotistical monster, and 2.) not getting better. Knowing that, allow some grace for yourself and the people who came before you.
I can’t say I’ve mastered this skill yet. Sometimes, in moments of frustration, I flat out suck at it. But I’m trying and that’s kind of the crux to all this. Everyone is trying, no one has arrived, and the more we empathize with the unknown constraints of those who came before us, the better off we’ll be.
Adapted from original link
So, um, this happened
While the Institute was being reorganized after the departure of Ed, until things got caught up in the HR system, our group was 3 levels below the Chairman of the Board…
Work BBQ
Two pictures from our group BBQ at the bosslady’s house. Good food (!), good wine, good laughs, and cows with bells. Rousing success!
Imposter syndrome, or when programming was no longer fun
I loved programming. I loved being able to create something out of nothing. Solving the puzzle of the program and seeing it come to life. Constantly learning new things while hours flew by, and better yet I was paid for it.
I went to one of the best universities in the country for computer science. I cruised into my first job after a successful summer placement. I loved my work and I did well. I moved from a junior position to senior position and was recognized for my hard work and contributions.
Somewhere along the line it stopped being fun. Suddenly I hated going to work. Every day I battled with a growing anxiety that would not go away.
What happened?
– I started comparing myself to other people that were better than me.
– I started to fear doing things wrong and being a failure.
– I started to fear not knowing enough and constantly tried to learn everything.
– I started to feel a crushing weight of responsibility for my job, partner, children, mortgage, and bills
– I started to fear that I would be exposed as a fake.
What I did not realize then is that I was facing a severe case of impostor syndrome.
Instead of enjoying my work I would constantly be worried that I did not know enough, and that I was not doing enough. That I was not providing enough value. I forgot about my accomplishments and emphasized any mistake I made as a complete failure. I started to seek perfection in a world where it’s impossible. Not only did I seek perfection but I expected it of everyone else. It was a recipe for stress and unhappiness.
I remember doing demos of my work in the past. I was confident and happy to do them in front of a number of people. Suddenly I dreaded them. I would become so nervous my voice would tremble as I tried to talk. My thinking was clouded by the dread of saying something stupid, and what others would think of me.
The crushing anxiety was preventing me from enjoying my work and doing well. It was taking its toll on my health. I would feel drained of energy and not sleep well. It was putting strain on my family and relationships. It felt like a ticking time bomb.
It has been stated that up to 70% of people experience impostor syndrome. The trouble is you feel like you’re the only one, as you’re not aware of anyone else going through it. There is a good chance that one of your co-workers is experiencing it right now, but it may not be obvious that something is wrong. It can manifest itself in different ways, and people are good at covering things up especially in a professional environment.
Some points for anyone experiencing it
– Recognize what you do know. It’s more than you think.
– Recognize what you have accomplished. You earned it.
– Take a compliment when you get one. You deserve it.
– Compare yourself only to yourself.
– Realize that nobody really knows what they are doing. Everyone is on a learning journey.
– It’s OK to not know everything. Software development is too vast and moves too quickly to know everything. Usually you know just as much as others but in different areas.
– Teach others, it will help you realise how much you do know.
– It’s OK to fail. In fact it’s a necessary and important part of life. Learn from it.
– It’s OK to be wrong. Be open to feedback.
– You will forget things over time. Go back over things you have not used recently.
– There will be egos in the workplace that talk down others. Ignore them.
– Not everything you produce needs to be perfect. Software development is (as is life) about incremental improvements. You are not that piece of code that you put together in a few hours and needs improving.
– Assume that everyone else has impostor syndrome. Tell someone when they have done something good. Tell them what they are good at. Tell them it’s OK if something goes wrong they did a great job. A small comment can go a long way. Having a team of people doing this for each other will foster a healthy environment. We are all human beings and everyone has fears and doubts. Everyone has problems and hardships they are facing outside of work. This idea often gets lost in the veil of professionalism, and we become ever more disconnected. Once we realize and appreciate this we can move towards a more personal and connected workplace.
I am not sure that the feeling of impostor syndrome will ever completely go away. Though it has faded since understanding and recognizing it. Knowing that many others experience it, and that it’s quite normal also helps. I am happy to say that I am getting back to a place where programming is fun.
Understand that it can hit you at any time. It may be when you’re just getting started in programming, or it may be when you have been doing it for 10 years. It may be when you have a newborn baby at home. It may be when you get made redundant and flunk an interview.
What is most important is an awareness of it. Take it seriously. When it does come knocking you can recognize it and work on it instead of letting it consume you. Connect with people and help them to prevent feeling like an impostor. Hopefully you will get the same in return. Lets work to ensure that programming is always enjoyable.
Original link: dev.to()