I think there is an experience for newer programmers where you've done the thing, you feel like you knew what you were doing, but you still have a hard time articulating the work.
How do you gain this understanding?
For further actions, you may consider blocking this person and/or reporting abuse
Top comments (13)
I’m not a talker, I’m terribly shy in unexpected social situations.
However, one thing that has helped me a lot is writing. I try journaling and writing my thoughts every day. I also see how my understanding of topics grows when I write at the end of processes — sort of like a longer
git commitstored somewhere else, explaining my line of thought and why I decided to do things this way, and pointing out anything learned through the process. I personally write everything in the same journal — I use the app Diarly for Mac.Writing is a great way of organizing and formulating your thoughts, letting them out of your system. Then, when you need to talk about it, it’s easier to remember, if you have already put it into (written) words once!
Absolutely right 👏🏽. This is why I started blogging.
Writing helps me make my thoughts clearer and coherent. Taking those thoughts and speaking them out is easer then.
It helps to be mindful of what level of detail to answer with. Most people don't need to know all the technical details.
To a stranger at a party: "I work at Google making Chromebooks."
To a techie: "I work on the firmware-testing framework for ChromeOS."
To a teammate: "I'm working on migrating the firmware-testing framework from Autotest to Tast."
To my private
notes.mdfile: "I'm exploring ways to extract the mode-switcher from Autotest, hopefully into a standalone executable. Right now I'm hoping I can leverage the existingdut_controlcommand, but it depends on what servo interfaces I need."I completely feel this! I remember an interview where I was asked: Explain how you would deploy a simple CRUD app from scratch. Something I have done dozens of times, but I still blanked out at the beginning 😅
I'm not sure if it's an issue with "understanding" - at least for me, it's more about having a verbal grasp on what I've done, such that I'm not retelling it as discrete tasks, but more as a cohesive story.
Like I can run down a list of tasks that i accomplished this week at work, but struggle with describing at a higher level what I've worked on, or accomplished.
Hope that makes sense.
Rubber ducky technique. That's how I study things anyway, it helps me a lot :)
Explaining the pieces as you go can be much easier than trying to recap the whole thing once you've finished. This also gives you a chance to refine your explanation when you do finish it.
Potentially a great opportunity for a mentor too, where you get feedback on how you are talking through something.
I'm a big time introvert and yes I'm admitting it on this platform. I have earned good amount of skills in my domain but often get scared or you can say, feel shy, to share my learnings or explain my projects.
To overcome this, what I have started is writing blogs, documentations, ReadMe files, Presentation which helps me and other developers or any person in an organisation to learn or to know what I have been working on.
Few tools which I use more often to write my notes or to share my learnings on public platform are:
After writing, I do share it with my colleagues, seniors, product owner, engineering head, etc. In this way, you don't have to say anything but your knowledge, learnings and thoughts are going everywhere and, if lucky, will get appreciated.
But I would personally suggest to enhance your networking skills, talk to people, atleast get into conversations.
Most of my job is talking about trade offs and providing recommendations.
It's actually a lot of fun, except when you face entrenched opinions that refuse to look at data.
It's about making informed trade offs, which means understanding all sodes of the argument the best I can.
I read about it. I read and I read some more. I no longer read about news, sports, politics, television, movies. Code and articles about it are 99% of my light reading.
It's hard to remember being a new programmer as this happened about 40 years ago.
I don't ever remember having trouble articulating what some work does
Mind you, I am not a great programmer. I am a good software engineer
The difference between the two things is that a programmer produces code. The engineer takes part in a set of processes that produce code
Part of most modern (lean, agile) processes are that communicating with your team, stakeholders and others is absolutely vital
When I started doing talks at meetups it became clear that a good tech talk is like telling a story.
So think of your code like a fairy tale. Set the scene. Introduce an unlikely protagonist. Explain a bizarre challenge. Describe the adventures of the protagonist. Resolve the story HAPPY EVER AFTER
Read job listings, and ask yourself how many of those things have you done. Make a list of all of those things that you have done. Make a list of the tools, languages, and technologies that you use. You will eventually wind up with a list of things that surprises even you. Be generous and include everything that you have touched at all. Then you can shake this out to the best pieces and include them (maybe even combining some of them) into your resume.