How to Make Meaningful Contributions in a Professional Engineering Organization

It’s good to develop healthy coding habits. Striving for perfection at all costs may lead to wasted time and resources, while focusing solely on speed and efficiency can sacrifice code quality and user experience. There is a delicate balance that every good programmer learns at some point in their career.

In a recent Seeker's meeting at the Nashville Software School, software engineer and NSS Web Development Cohort 7 alumna, Rebecca (Beck) Cronin-Dixon shed light on the significance of the "good enough" mindset in software development. 

By practicing effective time management, balancing learning with practicality, and emphasizing value delivery, Beck shared she was able to find the optimal balance between delivering functional solutions and continuously improving them in her workplace! Let’s look at how to put these principles into practice in your job.

Progress over Perfection

In Beck’s first developer job as an SEO engineer at Eventbrite, she initially struggled with perfectionism which hindered her progress.

“Starting off at Eventbrite, I was very junior. I'd done a little bit [of coding] before NSS with WordPress. [At] NSS, I did C# as my back-end language and I was now transitioning over to Python. I had not touched a lick of [Python]. I hadn't even done a tutorial until I got the job with Eventbrite,” she explained “So coming in, my whole plan was learning. My first few weeks were honestly just digging into code, finding small bugs and fixing those. But I did suffer from this perfectionism problem.

“I was trying my best to learn the language. But what I focused on was learning the syntax and [asking myself questions like], ‘what's the right option’ or ‘what’s the best thing I could do here?’,” she explained. “That took up a lot of my time. So instead of fixing a bug or providing a new feature for a user, I was trying to perfect my code, which was not the thing I should be doing [and had a high opportunity cost]. Early on, my manager sat me down and said, ‘What's taking so long with this ticket? Let's discuss it through and he helped me realize I didn't need to make it perfect. I needed to get a code review up so somebody else could sort of show me the way.”  

💡Put it into Practice!💡

Embrace progress by focusing on functionality and seeking feedback. Rather than striving for perfection, prioritize getting your code reviewed by colleagues or mentors who can provide guidance and help you improve. Remember that learning and growth come from iteration, not flawless execution.

Striking a Balance

One key lesson Beck learned in her first job at Eventbrite was the importance of finding the right balance in software development approaches. She shared the difference between being a "cowboy coder" who dives into coding without much planning and being an "astronaut" who meticulously plans every detail before writing code. 

“There's that analogy that you're a cowboy coder, or I prefer duct tape engineer, or you're an astronaut. You're either getting in there, brute forcing it and finding your requirements as you’re coding, [the cowboy], or you're thinking it through, planning every little thing before you ever [write a line of] code, [the astronaut].” She explains this as a spectrum between the two, and that a good developer strikes a balance between the two somewhere on that spectrum. 

Understanding Opportunity Cost

Spending time moving too fast or planning too long can come with opportunity cost. But, understanding opportunity cost isn’t something that’s learned overnight. As Beck shared with the seekers, finding balance is something that they will learn with time, with experience, with wins, and with failures. “It's just going to happen [one day],” she says. “But [while you’re learning], what you can do is find the things that matter. Find where on the spectrum you need [to be].” Every project may fall in a different place on the spectrum. By understanding the project, its timelines, the people you work with, the company, and its stakeholders, you’ll learn to get a sense of if you should be more like a cowboy coder or an astronaut. She emphasized the importance of understanding the codebase you are working with. Navigating and comprehending existing code will allow you to make informed decisions, contribute effectively to the project, and gain a broader understanding of the overall system.

💡Put it into Practice! 💡

Gain a deeper understanding of the project, codebase, timelines, and stakeholders to make informed decisions about your software development approach. Assess each project individually to determine whether a cowboy coder mindset or a structured, astronaut planning approach is required. Strive to find the right balance by considering the specific context and requirements of each project, allowing you to optimize your productivity and deliver successful outcomes.

Learning to Determine "Good Enough"

It’s easy to get caught up in the project itself before stepping back and asking the important questions to help you see the full picture. Beck shared her experience with a project that suffered from scope creep, “I had the duct tape programming moment mid-career when I was building data pipelines at Eventbrite,” she explained. “A lot of times we would just be given these very ambiguous tasks. We didn't ask why. We went and built these pipelines, mainly because it was fun to write, like, it was just fun to dig in the data and do that,” she laughed. “I realized quite early on that there were a lot of [things] I didn't know [or] I didn't think about upfront. So then I had to go back and say to [the team], ‘Hey, I can't get this done in the time frame that I told you’.” 

Part of determining what “good enough” at your company can come from asking senior developers to help you understand what they’re looking for in an MVP. “They will know what's ‘good’ in ‘good enough’,” Beck says. “They'll know the scope.”

Beck stressed that as you’re learning the “good enough” mindset, not to be too harsh on yourself for the hours spent on projects that don’t see the light of day. “We could have been working on more critical things, really. And we went on like that even on the good enough scale, like we just didn't have enough questions to know what ‘good enough’ was, because ‘good enough’ also doesn't mean it's just out there. It means that [what you’re building will] be useful, it'll be valuable. Another part of ‘good enough’ that you can get trapped in is if you don't build things like that, things are going to be built in a way that is modularized.” 

As software engineers, it’s easy to be “haughty” or “judgmental” of code that you might work with. Beck says this is because you see the code and probably would have solved it differently, even though you don't have the full context. “[Context] is so important as you're looking into code bases and solving bugs and trying to determine if it's what I'm looking at ‘good enough’?” she says. “Does it work? Has it worked over time? That's probably good. Move on. And you've got other problems you can solve on behalf of the business.”

💡Put it into Practice! 💡

Embrace the "good enough" mindset by seeking guidance from senior developers to understand the criteria for a Minimum Viable Product (MVP) in your company. Communicate openly with the team to clarify project requirements and avoid scope creep. Prioritize delivering functional solutions that meet user needs and align with business objectives, rather than getting caught up in perfectionism or spending excessive time on non-essential tasks.

The bottom line? When you’re trying to determine if a code base is “good enough”, communication is key. By embracing the “good enough” mindset, developers can create successful products that meet the needs of users while being mindful of time constraints and business objectives, striking the balance between delivering functional solutions and avoiding perfectionism!