Software Engineering in Practice

These maps already exist but are obscured to you. Be alert to facts that affect your projects or organization. Continually sift information out of the noise around you, e.g., a shift in corporate priorities could mean a platform you’d considered but backburnered has become an amazing investment. The Locator Map: Getting Perspective Time you spend absorbed in any domain increases your depth and understanding, but it comes with some risks, e....

On the Clean Code Movement Good enough is good enough. The architectural choices and bugs in the implementation tend to be more impactful, so focus more on those. Be conservative in what you consider technical debt. It should be something that slows down current/future changes, and not code that doesn’t “feel nice”. A code base that is free if technical debt is likely over-emphasizing polish over delivery. Abstractions and indirections in the name of future-proofing tend to be wrong especially when treading new paths, where you can’t reliably predict the future....

Stuck in Traffic Thinking through both sides of these scenarios can help me reduce the times when I (or my team) is the blocker. Blocked By Another Team Understand and explain. Why is the work is important? What do you want from them and by when? Give them another chance to indicate feasibility and/or alternatives. Make the work easier. Can you ask for a smaller subset of features?...

Create clarity for everyone such that they know what they need to do and how it fits into the bigger picture. Communicate openly. Give team members a stage to be publicly competent. Pick up the grunt work that others might not find enjoyable. Allocate time for support work, e.g., reviewing user feedback and error reports. Usually, the reason a project is difficult isn’t that you’re pushing the boundaries of technology, it’s that you’re dealing with ambiguity: unclear direction; messy, complicated humans; or legacy systems with behavior you can’t predict....

Measuring Productivity Devs' Diverging Perceptions of Productivity Got interested in measuring it two years into my SWE career. Initially rated myself based on % of completed daily objectives. The objectives didn’t necessarily correspond to work items. Stopped because the numbers were high even on days when I didn’t feel productive. Switched to “stuff that affects others” (later came to know these are “function points”). More intuitively captures non-code objectives, e.g., aligning folks on feature specs....

Deliberately choose what to work on. Part of that is getting priority communicated by interested shareholders. Empower less-experienced engineers so that they’re confident tackling different problems instead of me having to pick up said problems. Improve my investigation and writing skills so that I can give folks enough context to execute on their own. Mostly communicating intent and trusting others to figure out the nitty gritty details. Origins of Projects You’re invited to join....