bentoncreation

My teenage son knocked on our bedroom door last night after we'd all gone to bed. He was crying and told us his cousin had just texted him the news, and then he watched the video. We watched it again together. I cried and hugged him and we talked about it a little bit.

My kids were so isolated during covid lockdown, we were getting really worried for their mental state. They weren't seeing other kids their age, they felt like they had no friends, and there was one point when it seemed like they even stopped missing other people altogether.

But my son, especially, was deep into Minecraft Youtube at the time, and I could tell that this cast of creators was really important to him. It often felt like he was on a call with his fun and hilarious buddies, just on mute.

I think Technoblade, and other creators like him, helped get my son through the past couple years. I'm so grateful to him for that.

> Time tracking is self sabotage.

That's a bit extreme. Lots of people track time and hourly billing is common in many industries. If it was self sabotage, the practice would have died out naturally.

> It's better to estimate the hours required, quote for those hours and agree a completion date in advance.

I think project-based pricing can work well if you have clearly-defined scope, if you've solved this kind of problem before and there aren't many unknown unknowns, and you invest in a lot of upfront planning and estimation.

Most of my work hasn't been like this. I'm usually filling a role, not completing a single, well-defined project. And I'm often solving problems that I haven't solved before, where a client and I are uncovering complexity as we go.

> With time tracking you're inviting unnecessary scrutiny and failing to establish work boundaries that can leave the client with no sense of beginning and end.

I could see this being the case with micromanagers and toxic clients. But I think time tracking and sharing a certain level of detail at regular intervals helps clients, and potentially other team members, understand the effort needed for various activities. That helps everyone build their sense of what it takes to complete the work.

> Upfront estimation with deadline gives them the peace of mind they need, establishes the boundaries and frees you to get on with the job.

Peace of mind comes down to trust. And trust can come from a SOW/contract, as well as from a relationship that's built through clear, regular communication and delivering incremental value over time. The contract is important, but that's the low bar of trust.

> If you underestimate do better next time, if you overestimate then great have a margarita.

In my experience, software project estimation is very difficult and the risks grow with the size of the project. At a certain size, if your estimates are wrong for a flat-fee projects, there may not be a "next time."

It's currently fashionable to hate on hourly billing, but I personally don't know how I'd make it as a consultant if I switched to project-based pricing. And yes, I'm familiar with Jonathan Stark's writing on the topic. More power to people that can make that work!

Yeah, design is a separate discipline from programming and has to be considered on it's own. It can't be boiled down to just a set of techniques (Photoshop techniques, in this case). It's important to learn design theory (what you'll get from those Peepcode play-by-plays or from some good design books) and the practical techniques (what you'll get from sites like http://psd.tutsplus.com).

I'd recommend tackling both design theory and Photoshop techniques, unless your only interest is in implementing other people's design work and you just need to know Photoshop techniques to translate that work from PSD to HTML/CSS.

Communities are really good at providing social rewards for certain behaviors. It would be nice to see a community like this include mechanics to reward those who "complete" their side projects. Shipping side projects is hard. This could provide additional, helpful incentive.