So I know I’m quite late to the topic, but way back in week 1 or 2 we went over the POGIL roles, responsibilities and basic structure. This for me has always been about learning to work in a team, regardless of the assigned jobs on the card – and I have to admit I’ve always had a hands off approach. I wouldn’t say I’m a bad team member, just an absent one. I wasn’t always engaged, and just wanted to meet some arbitrary requisite for a good enough grade. I’ve obviously adapted as projects and activities got harder, but this podcast episode seems to have broken me out of that passive mindset into something much more productive.
There is a bit of a disconnect here from myself to the podcasters, as they are experienced developers with years of managing experience, but nonetheless I think it helped me glance into a world that I knew absolutely nothing about. Kind of like a peek behind the curtain of what I should be expecting. My greatest takeaway is always defer to someone who has even a tad more expertise with a certain context. There’s simply too much to keep up with, and in order to do your job effectively, one must make a choice to lean into a specific type of architecture. Just be good at what you’re supposed to be good is my takeaway, I guess. Other peoples’ expertise will help whatever the team is working on, and your personal experience will almost always prove to be invaluable at some point in the project.
In addition, I think I’ve picked up a habit of deferring to other peoples’ techniques when solving a problem. I of course will point out if I think I see an error or bug, but it gives me a sense of wonder seeing how many different solutions people can come up with to a singular problem. There is so much ingenuity inherent to coders that it’s never a good idea to say “this is the way things should be done.” My father is an architect who advises some up and comers, and when I ask him, he is regularly annoyed with staff for not doing things “the right way.” I love the guy, don’t get me wrong, but after listening to the episode I have to say that this technique is too suffocating. Just like in architecture, writing code is an expression of will or intent through creation. To limit that in either capacity is unhealthy for the people who would pour their heart into the work.
I suppose that’s a bit philosophical, but nonetheless it’s a lesson I’m glad that I’ve been exposed to. Other nuggets in the episode are tips on efficiency and cohesion, but these two concepts are what really stuck with me.
Link to Episode – https://content.blubrry.com/completedeveloperpodcast/CDP-Episode0319_Your_Code_Sucks.mp3
From the blog CS@worcester – Dummies that Code by howbrash and used with permission of the author. All other rights reserved by the author.