HackerTrans
トップ新着トレンドコメント過去質問紹介求人

programzeta

no profile record

コメント

programzeta
·3 年前·議論
I think this depends greatly on the product area and ease of updating. Removing problems categorically from designs early has been valuable to me in the past to reduce surface area, avoid impossible refactoring, and eliminate systemic bug classes.
programzeta
·3 年前·議論
Being unwilling to even try talk through your emotions with the /person who you are going to marry/ is absolutely a bad signal and deal breaker.
programzeta
·3 年前·議論
It’s not life or death, but time spent dealing with errors - debugging, the direct effects, understanding full impact - isn’t a resource we can get back.
programzeta
·3 年前·議論
Thank you for asking this, it helped tease out and crystalize some thoughts I’ve had about the difference in tenor between computer programming and software engineering. I hope these off-the-cuff answers help explain why this doesn’t feel quippy to me; they are specific in scope but those scopes are common.

—

Write clear error messages that provide a way forward. Accept your system will have bugs, and ensure the system state is communicated to the user so they know if their TODO/Test/Reminder/Wish was stored/updated/deleted. Do your utmost to prevent data loss - even when that data hasn’t been formally introduced to your data storage of choice.

Developers should not worry about their sprints being blown because they have to use your APIs. Teams trying to pass off tasks or getting special commendations for dealing with your software should be embarrassing. If developers are wrapping your API in their API, are they doing it because they need the abstraction or because abstracting it once and tracking changes is easier than using it?

Ensure there are logs in place to assist debugging and documentation catered towards end-users, operations, support, and developers. Track relevant metrics to allow for automated fixes and manual intervention so users aren’t the ones having to remind you your software is broken.

Every piece of software has a user - a person, an organization, other code - and software that doesn’t make the user’s life easier increases the chance they’ll stop using it.

Or worse, start using it incorrectly!
programzeta
·3 年前·議論
Hear-hear for Flowdock. Been a decade and I still can't help but think of it when I bump into the latest annoying Slack-ism.
programzeta
·3 年前·議論
(c) could be re-written as “If you’re going to give gifts, make them personally meaningful and not generic.” I think this advice is most relevant when you’re doing personal, one-on-one concierge or consulting. When you have lower contact rates with people, small things such as this reassure that they are not “out of sight, out of mind”. Your mileage may vary based on your role, employer, and field :)
programzeta
·3 年前·議論
It’s been my experience that without regulatory heat it takes a massive, embarrassing mistake to get traction on internal tool lockdowns and security.
programzeta
·3 年前·議論
The forum (as well as ‘stage’ and ‘announcement’) feature requires changing to a “community” instance which has some other strings attached. AFAICT long-running servers would never know the new setting is available.