alxmng

In my experience a culture of urgency has been the most reliable indicator of a mismanaged or toxic workplace.

You might be thinking of “Foursquare” :)

Enterprise sales is essentially just promising more and more features that don’t exist until they sign a contract, then developing the crappiest least-effort implementation to not lose the contract.

Yes, database connections are password protected.

That's correct. We used to use CloudFlare, but it added too much time to each request (speed is important to us). So now it's just pointed directly at the VPS.

Crashes are logged but I don't think anybody has ever looked at the logs. I'm not sure a crash has ever happened (the app is written in Haskell). Unexpected errors are saved to the database and can be viewed using the web. If we needed logs people could tail them from the VPS (ssh -t $WEB_HOST 'tail -f webserver.error.log'). I know, I know, that's crazy. I'm told real software companies are supposed to ship them to someone else, and then pay them to view the logs using a crappy web interface.

No monitoring. If the site is down customers will let us know, which has happened a few times. Monitoring wouldn't help much with shipping bugs anyway.

Yeah, every so often I spend 5 minutes and run apt upgrade. I don't think the DB has ever been upgraded because there's no reason to. It's not exposed to the Internet anyway.

4 people but sometimes 10 with contractors.

Sure, there's downtime when the VPS provider is down. That's no different than "managed" services.

A $40/mo VPS. Caddy web server. Supervisor to restart automatically. Git to deploy. CI using GitHub actions which build, run tests, and push to server on success. Automatic VPS snapshots and a cronjob to backup the DB to cloud storage. DB runs on the same box.

This has worked for years with practically zero maintenance.

“RESTful” API design is mostly bike-shedding.

There’s no standard. Every REST API looks different. Clients have to refer to documentation anyway, so consistent URL patterns achieve nothing. People waste large amounts of time over totally inconsequential minutiae like whether to use singular or plural words in URLs.

Separating idempotent calls from non-idempotent calls is useful, but REST overcomplicates this. All that’s needed is read and write calls, yet REST has get, post, patch, put, delete…

REST is also inefficient. Clients could read the data they need in one HTTP request, but most “RESTful” APIs force clients to make many requests for the sake of what is essentially aesthetics.

I couldn’t agree more. It’s a culture problem. A culture of carelessness and corner-cutting pervades the software industry.

I cannot understand taxation for the sake of taxation. The purpose of taxation is to divert those funds to pay for something.

"We want to fund a new healthcare program, so we are going to pay for it by an increase in taxes" makes sense.

"We want to tax billionaires because they should pay more tax" does not make any sense.

Good luck with that. I had my account frozen at the biggest bank in USA, with no notice or explanation. When I went into the bank they pretty much said "sorry". Almost two weeks later my account was unfrozen again without notice or explanation.

I've mostly replaced my iPhone with an Apple Watch. It has cellular connectivity so I can text/call/pay. I leave the phone at home and pretty much forget about it.

You can lease IPs without bad reputation and run your own servers, but that doesn't make sense if you only want to send transactional emails for a web service.

I've had good experience with Postmark. Like any transactional email provider, there's an approval process and you need to be using it only for transactional email for services which maintain a low "mark as spam" rate.

The military blocks Facebook (and Twitter), but everyone uses it via VPN (including members of the military). Online commerce is popular, and the majority of online commerce happens on Facebook with cash-on-delivery.

The conflicts exist along ethnic lines, but all major armed ethnic groups had formed a government together at end of WWII, and even today many of the groups openly support a federal union.

Settlers and natives has nothing to do with it. All the major armed ethnic peoples existed in Myanmar since before WWII. The “settlers” were the British and they left.

Agreed. Myanmar has been at civil war since WWII. The Tatmadaw viewed Arakan muslims as enemies for decades before Facebook. In the 1980s they had policies against them. And that's just one conflict in Myanmar. The Tatmadaw has been killing Shan, Karen, and other ethnic groups for 70 years. The Karen conflict is one of the longest running conflicts in the world. They're bombing Karen and Sagaing villages right now. Facebook is inconsequential to Myanmar's bloody politics.

It's true there are problems with Facebook. But without Facebook the Tatmadaw would still have laws against Rohingya, still have a policy of driving them out, still would engage in fighting ARSA, still would fund and promote groups like Ma Ba Tha, etc.

Using Apple/iCloud for everything, and getting rid of other services and software. One low monthly payment. Seamless integration between devices. Easy sharing of purchases, photos, or other media. Apple has an app for everything we need (notes, reminders, calendar, browsing, music, videos, password manager, photos, videos, etc.) No need for shared email as we use a shared bank account, and Apple Pay/Wallet supports shared cards (Apple Card also has a co-owner/family support).

It depends. I do plenty of billable hours augmenting software teams. I'm delivering user stories every week. There's simply too much communication overhead in preparing weekly estimates for the same client.

I don't share the perspective on hourly making someone a commodity. Fixed outcomes can also be commodities. Clients can and do shop around estimates for the best price. The race to the bottom exists whether you're billing by hour or by outcome. You avoid the race to the bottom by what you sell, not how you bill. Wordpress themes are mostly a race to the bottom, regardless of how you're billing.

Route everything to email. Use your email to interact instead.

Thanks! Good to know.

I’d say the biggest difference was:

1) A product owner that articulated clear and granular user stories with acceptance criteria, and kept them prioritized. Sprint planning was quick and easy as a result, and developers had freedom to design and implement the story within those constraints.

2) A good engineering manager (scrum master) that insulated the team from pressure from product owner, and ensured product backlog was well articulated and sprint backlog was reasonable and practical.

Both of these things are clearly described by The Scrum Guide and how scrum should work.

This can be boiled down to trust: Is the company a high-trust environment where people are respected, or a low-trust environment where people are treated as machines. Sadly in my experience, most of this industry is the latter.

I’ve had good experience with actual Scrum, as described by The Scrum Guide (https://scrumguides.org/scrum-guide.html).

I have had terrible experiences with bastard scrum: Standups as manager reports, sprints as death marches, stories without a definition of ready or done, stories added during the sprint, no backlog refinement, etc.

In my experience many companies doing “scrum” are actually doing daily manager reports and weekly top-down deadlines of fixed scope, while calling these “standup” and “sprints”.

In my 15-year career I’ve only worked with one company doing real Scrum, and all the companies doing bastard scrum were startups.

I’ve experienced this more than once. I think code review is best used only for finding defects (bugs). Otherwise, it consists of demoralizing comments and bikeshedding.

Not all cultures have a family name. Myanmar for example, has no family names. There is only a given name, which is often many words.

Just store a name field, and if you need to interface with other systems with multiple name fields, ask the user to fill those fields out.

Sure, if they had many passwords from different services and then cracked the formula. It was deterministic based on company name but not immediately obvious. I had a separate “master” password for email and computer, because those were more important.

Worked for me for 20 years.

No need for a manager. Use a simple formula based on the company or service name. That way you can remember one base password and slightly modify it for any service. No need to copy and paste, no need to trust other companies with all of your passwords. No need for any software.

I haven’t thought about passwords in at least 5 years since I started using Apple + iCloud. Apple has native password management baked into everything. My face or thumb logs me in, whether I’m using laptop or phone. When creating accounts I just use the auto-fill and generated password.

Productivity is the ratio of output to input.

Code is the output of a programmer. Time (or wages) is the primary economic input to software development.

Productivity is not a measure of whether something is worth doing. It says nothing about whether the code is valuable or worth writing. A factory has increased productivity if it has produced more widgets with the same inputs, even if nobody wants those widgets or those widgets pollute the environment.

Similarly, programmers do not choose what software to write. They are employed to write software someone else decides is valuable to the business. Their productivity is independent of whether the software has business value.

Consider a one line program. A programmer that produces that program in 5 minutes is more productive than one who produces it in 1 hour.

Stories with sizes are proxies for magnitude of code change or time. A larger project is larger because it takes more time or more code change, or both. Story size/points is an attempt to estimate this. So it is more accurate to measure the actual code change and time taken.

It’s true that the same program can be written with different amounts of code. But this is largely irrelevant at the organization level, where programmers are not writing multiple versions of same program in different languages and toolsets. A team is typically writing software within the context of a particular toolchain and runtime environment.

The material output of programmers is code. In that sense, programmer productivity is (|additions| + |deletions|) / time. Economically, it’s (|additions| + |deletions|) / wages paid.

This is how I would quantitatively measure the productivity of members on the teams I work with. If you look at this measure across your team, I think you’ll find it roughly matches your intuitive notion of who the most productive programmers are. I also think you’ll find story size positively correlated with the magnitude of code change or time.

The thing is, measuring how fast programmers output software isn’t all that useful.

Why do you want to measure productivity?

You already know where you are. A measurement doesn’t help your team ship better or faster.

If you’re shipping product improvements at a regular cadence, and the customers are happy, then there’s no problem with productivity.

If you’re shipping poor quality, identify why and improve that.

If you’re shipping so slow that it’s negatively impacting customers, identify why and improve that.

Shoot me an email, I’d be happy to offer more perspective or advice.