161–170 of 290 posts
Consistently and reliably delivering good software solutions. Just like a master woodworker would consistently and reliably deliver good furniture. Or a master author would consistently and reliably deliver good books. The key points are: * Consistent - It wasn't just a fluke or luck, you know what you're doing and can repeat it. * Reliable - You know how much effort it will take and can deliver it. * Good - It's not…
Earlier quoted context omitted.
I can give you an example from my career. We were building out a new webapp feature to deliver medical textbooks, which we had as xml documents direct from the publisher. Our customers, mostly large academic libraries and medical research companies, would get the electronic access to the books for much less than it would cost to get sufficient physical copies, and our cost for supplying the books would be minimal. A…
Precisely the reason why next time you would consider debating what's in it for me, prior to blurting out a solution.
Software Engineering doesn't exist in isolation. You can't master Software Engineering without mastering interfacing with the rest of the organisation. I don't care how intellectually pure your implementation is or how fast you deliver things. If it can't easily connect to, use and get used by the rest of the business, it's a folly. A master of software engineering delivers what the business needs in the minimum time…
Yes, that's right. It's also a choice. You don't have to work for a company who does not care about maintenance.
At least I wouldn't, people should have own their standards.
With that codebase you are going to spend your 1/3 of your days. It really matters.
Earlier quoted context omitted.
Prototyping alternative solutions is a cheap way to help uncover trade-offs, and you can do this independently. Attending retrospectives after things go wrong is a good way for experts to introduce their thought processes to less experienced engineers. Asking "why?" when senior engineers deliver feedback during design review can help you learn that a trade-off existed when you did not see it.
I once was trying to design a validation framework. I thought it should work this way. The other lead thought it should work that way. So I proposed we write some sample code for these APIs and show it to the team. TDD with pseudocode before any of us knew what TDD was. Only, I didn’t like having two to chose from. Something told me three would be better. So we paired, I wrote mine, then hers, then just made another…
IMO it's about understanding the solution curve in the problem space. Every problem type has a range of possible solutions. Most of these solutions are wrong and a few are correct with different tradeoffs. When you can't do better without making tradeoffs, you're on the curve. Novice engineers will struggle to get something done. Intermediate engineers can get things done but fail to see the tradeoffs. Expert enginee…
Now, you might be thinking "that's not true, if I implement a function to add two numbers, and it returns 1+1=3, that's wrong. So that's a clearly wrong solution." But I argue: is it wrong? What's your context? What are your acceptable trade-offs? In many real-world applications, precise correctness isn't always critical. Sometimes, sacrificing accuracy might be acceptable, and may save on cost and/or complexity. Other times, that's not acceptable. But it's worth considering even these types of non-obvious trade-offs, not just the obvious ones. That's what an expert engineer does: ask the right questions and identify the right trade-offs, and they've become efficient in that process from experience.
An expert sees a problem space as a wide range of trade-off dimensions, including:
* computational performance
* memory performance
* implementation complexity
* maintenance complexity (understandability)
* accuracy
* reusability
* design time
* reliability
* debuggability
* bug-proneness
* scalability
* etc.Earlier quoted context omitted.
I can give you an example from my career. We were building out a new webapp feature to deliver medical textbooks, which we had as xml documents direct from the publisher. Our customers, mostly large academic libraries and medical research companies, would get the electronic access to the books for much less than it would cost to get sufficient physical copies, and our cost for supplying the books would be minimal. A…
It seems like this value you brought in is "outside" the domain of software engineering, however. Yes, the solution ended up being found in software engineering, but the problem came from a business operation thing, no? (I wish you had gotten more thoroughly compensated for saving them a fortune.)
I don't know, but I one practice along my journey has had a surprising impact upon my skill development. That one thing is: I started coding in VIM. For some reason, making that change has improved my thinking, and that's been a big part of my growth. So, maybe you'll find that to be a helpful practice as well. It's worth a try.
I don't want to sound over critical. It's not about the vim. Can you generalize it a bit more? Let me take a shot at it(!?) You introduced a new tool to your workflow. The consequences of that was - Lower productivity initially - You where forced to think about how you create/edit your code So, what made it work for you? - Thinking about how you structure and edit your code. This gave you some clarity around how to t…
What I think it did for me is two things:
- the splits allows me to have multiple files (aka buffers) open at ones time and this might decrease the number of times I have costly context switches.
- the vi way of manipulating text is faster and more efficient in terms of steps needed to complete an edit. I believe this reduces the cognitive load of mundane tasks and lets my mind stay focused on the actual problem I'm solving.
VI may not help everyone obviously. But I think it opened a flood gate for me.
Also the initial lower productivity wasn't really that bad so I don't think it had too much of an impact.
Earlier quoted context omitted.
OP is giving a problem solving framework, it's not tied to specific solutions or tradeoffs. It's more of a method for thinking through a solution. In more detail, the steps go like this. Find as many solutions to a given problem as you can. Bad engineers run with the first solution that comes to mind, letting confirmation bias drive them. Evaluate each solution for its costs and benefits. Imagine two steps in the fut…
This comment made me realize what my mentor did years ago. He would have the entire team list all possible solutions to a problem, including the obviously bad ones, then have us whittle down the list based on pros and cons of each until we reached consensus on what to do. It was a teaching exercise and I didn’t realize it. I’ve repeated it that exercise with junior engineers to great effect. Some catch on over time a…
The best software engineers know when to solve a problem without using any code at all, like the classic "just do it manually" for a complicated task that is worth more than $x per task.