diiq

SEEKING WORK | Remote (happy to travel for kickoff, though) | Michigan, USA

I'm Sam Bleckley, a full stack engineer with 2 decades of successful outcomes consulting across dozens of industries. I can help with:

- Technical challenges ("We know the feature we want, but we don't have the expertise or the time to get it built")

- Process challenges ("We keep missing deadlines," "We're deploying too many bugs," or "The team has no motivation")

- Product design challenges ("We believe this solves our users' problems, but they aren't using it they way we expect")

I also offer fixed-bid development of small prototypes and MVPs, if you need to prove an idea, or have a new project hit the ground running.

If you're looking for experience in a specific tech stack, here are some of the technologies I'm comfortable using:

```AngularJS, Angular, AWS (S3, Lambda, RDS, &c.), C, CSS, Creative Cloud, Flask, git, Glamor, GCS, HTML, Javascript/ECMAscript, Lisps of many varieties, Next.js, Node, Photoshop, Python, Ruby on Rails, React, Ruby, SASS, SCSS, Svelte, Swift, Typescript, Vue, whatever legacy DSL you've got ```

If you want to know more about me, the services I provide, or my approach to software, check out https://sambleckley.com, or reach out to sam@sambleckley.com

Tip: if you open your comment with SEEKING FREELANCER (as the instructions suggest), you may get more leads

SEEKING WORK | Remote | Michigan, USA

I'm Sam Bleckley, a full stack engineer with over 2 decades of experience consulting across dozens of industries. I can help with:

- Technical challenges ("We know the feature we want, but we don't have the expertise or the time to get it built")

- Process challenges ("We keep missing deadlines," "We're deploying too many bugs," or "The team has no motivation")

- Product design challenges ("We believe this solves our users' problems, but they still aren't using it")

I also offer fixed-bid development of small prototypes and MVPs, for the right project.

For people using text search, here are some of the technologies I'm comfortable using:

  AngularJS, Angular, AWS (S3, Lambda, RDS, &c.), C, CSS, Creative Cloud, Flask, git, Glamor, GCS, HTML, Javascript/ECMAscript, Lisps of many varieties, Next.js, Node, Photoshop, Python, Ruby on Rails, React, Ruby, SASS, SCSS, Svelte, Swift, Typescript, Vue, and whatever legacy DSL you've got

SEEKING WORK | United States / Michigan | Remote | Full Stack Software Engineer and Designer

I'm a software engineer and designer with 2 decades of experience across a wide range of industries, from B2B factory-floor logistics to language design to cute consumer web apps. I specialize in helping small teams solve tricky technical and process problems, quickly. Is your team not delivering as fast as you expect? Are you dealing with more bugs or more setbacks than you think you should? Is there some tricky architectural or design problem you can't crack on your own? I can help push your codebase and your team to improve, so that you'll be running on greased rails even after our contract is done.

For people using text search, here are some of the technologies I'm comfortable using:

    AngularJS, Angular, AWS (S3, Lambda, RDS, &c.), C, CSS, Creative Cloud, Flask, git, mercurial, svn, darcs, Glamor, GCS, HTML, Javascript/ECMAscript, Lisps of many varieties, Next.js, Photoshop, Python, Ruby on Rails, React, Ruby, SASS, SCSS, Svelte, Swift, Typescript, Vue

SEEKING WORK | United States / Michigan | Remote | Full Stack Software Engineer and Designer

I'm a software engineer and designer with 2 decades of experience across a wide range of industries, from B2B factory-floor logistics to language design to cute consumer web apps. I specialize in helping small teams solve tricky technical and process problems. Is your team not delivering as fast as you expect? Are you dealing with more bugs or more setbacks than you think you should? Is there some tricky architectural or design problem you can't crack on your own? I can help push your codebase and your team improve, so that you'll be running on greased rails even after our contract is done.

Here are some of the technologies I'm comfortable working with:

    AngularJS, Angular, AWS (S3, Lambda, RDS, &c.), C, CSS, Creative Cloud, Flask, git, mercurial, svn, darcs, Glamor, GCS, HTML, Javascript/ECMAscript, Lisps of many varieties, Next, Photoshop, Python, Ruby on Rails, React, Ruby, SASS, SCSS, Svelte, Swift, Typescript, Vue

I absolutely agree that an arbitrary line can be drawn; I don't see that that line can be clear and bright enough that forms the kind of precedence that can be relied upon by folks who don't have the money to fight an uncertain battle in court.

But would be overjoyed to be proven wrong.

Author here! As noted in another reply, I'm using a custom justification tool I built almost a decade ago called unjustifiable.

The way it goes about it very silly; you can read more about it at https://sambleckley.com/writing/text-justification.html

That is also valuable, but a different premise! Barbara Sher originally wrote books based on that premise: find Your Thing and you'll shine -- but discovered that some people didn't seem to have A Thing, and any talk of having A Thing made them stressed and unhappy.

The Barbara Sher book for people who want to find and follow Their Purpose is "I Could Do Anything If I Only Knew What It Was". "Refuse to Choose" is for people who want to do 70 things but the thought of doing any one of them exclusively is horrifying.

You don't need focus; you need to understand what your goal is. If you're dropping projects that look "unfinished" because, in reality, you've gotten what you want from them, that is fine. It only looks sloppy from the outside.

If you're dropping projects before you get what you want from them, introspect on why. What's happening that leads you away? Address that.

I recommend reading Barbara Sher's "Refuse to Choose"; it provides some useful tools for people who like to do 70 different things, including how to have lots of ideas without having to act on every one immediately.

This appears to be based on a strange assumption that developers' estimates can't take historical work into account, but dev managers' can; and that estimates coming from dev managers and based on historical work will not be questioned for being too high even in orgs where the devs' estimates will.

I'm not sure the prescription given fits the disease described; it feels more like passing the problem on to a different role than actually changing the approach.

Absolutely, extensive notes are a huge part of my practice both on teams and solo [1] -- I'm trying to say "solve the problems you actually have" not "when solo, cowboy-code everything like a madman".

[1] https://sambleckley.com/writing/lab-notebooks.html

Pretty much anyone you can pay to host a database, you can pay to back it up. Amazon rds, heroku postgres, google cloud sql... pick the service that works for you, and they have some affordance for backups. Backups are something I expect, rather than something I shop around for.

Lots and lots of best practice exists specifically to help teams, and especially teams with some normal amount of turnover.

The problems of a solo dev are very different than a dev on a team. Knowledge silos don't exist. Distributed expertise doesn't exist. There's no one to mentor, no shared vision to maintain, no intertia to combat.

I consult on big complicated team projects. I also manage multiple solo projects.

On solo projects, deployment is a script I run from my dev machine. I'm the only person who deploys; anything else would be solving a problem I don't have.

The only "CI" is running the tests before I run the deployment script. I'm the only one who needs to see the outcome of the tests. Anything more would be solving a problem I don't have.

Architecture is whatever makes the most sense to me personally -- which is often miles away from what I would recommend to a client, who needs something any new hire will recognize and be able to work with.

I pay a service to manage backups so I can walk away from a solo project for months and know it's ticking away.

The point is: solve problems you actually have. Don't try to run a "professional" operation by doing what big teams do all by yourself. Big teams have different problems.

If you don't want to script your own, Vistimo Quotes lets you do monte-carlo simulation with vague, uncertain estimates; and lets you play with variables like the number of people working, vacation time, etc.

https://quotes.vistimo.com

I use a statistical model, where each task gets a "best case" and "worst case" estimate; those estimates are used to create a log normal distribution, and the project is simulated as the sum of those distributions plus sick days, social loafing, etc.

I use that method for all my consulting estimates, and it has been very reliable for me; no crunch time, and I often come in under time. I've also made a tool that does the math so my clients and other people can continue to use the same process without me.

[1] https://quotes.vistimo.com/

I suppose if you consider software to be somehow magically different than all the other human activities which go over-time or over-budget, maybe you could claim that research doesn't apply. But I guess I'd still expect you to know about the fundamentals of the multiple researched approaches to getting experts to predict accurate numbers in the face of uncertainty and social pressure, before deciding to discount it entirely for our specific field.

But it's certainly made a big difference for me in practice, and given the gushing about Steve McConnell in another comment thread, I'm not alone.

Forty volumes of the "Journal of Forecasting" would be a place to start for peer-reviewed articles, I guess

https://onlinelibrary.wiley.com/toc/1099131x/current

Would upvote twice if I could -- These are 5-star rules of thumb.

(I'm glad to see lognormal making more inroads in software estimation. McConnell is great, but assuming the normal distribution leads to some weird edge cases.)

1) The big if is written out in the abstract -- "if it is accepted that algorithmic complexity is an appropriate definition of the complexity of a programming project." Relating algorithmic complexity to "how long software takes to write" seems, to me, to ignore that the vast majority of my time as a developer is spent discovering and communicating requirements, handling human questions, not writing novel code. The conclusion touches on this, but ignores it.

2) Even if you accept that "if", this is like a halting-problem proof. Fine; it is impossible to estimate the complexity of ALL software. That does not mean that it's useless to quantify the complexity of software in limited but well-behaved problem spaces. How much of any commercial project is actually spent working on the cutting edge of computer science, facing complete unknowns? An estimate being wrong occasionally is worth most estimates being mostly right.

3) Why do you consider a 20 year old paper that's only been cited 16 times to be critical reading about estimation, when a vast body of research in forecasting exists, written by people who have measurements of the accuracy of estimates to base their theoretical models on?

McConnell's 50/90 approach makes a big difference in my opinion because it lets you encode your uncertainty. The extra math means you don't need to be good at estimation as long as you know roughly how bad you are at it.

If that seems like too much effort, I also run quotes.vistimo.com , which takes a similarly (if slightly more advanced) statistical approach, but does all the math for you.

That makes sense! I am constantly interacting with new teams, so I like time because everyone already knows what a day is. A ticket, or a point, or other abstraction changes from team to team and project to project.

Not trying to be snarky, I just didn't understand what you needed. Json import is not something any other users have brought up, but I'm happy to look into it.

I'm working on CSV export, first, but I will absolutely keep this in mind.

It's been my experience that most business needs involving estimates can't wait until the job is partway done. "Can we afford this" and "should we do this now" really need some up front answers :)

Vistimo Quotes is specifically for producing rapid estimates that don't require team buy-in, sign-up, etc.

Vistimo (https://www.vistimo.com) does anonymous, asynchronous team estimation -- but the additional labor costs (sufficiently describing tasks to async folk understand them, managing team permissions, requesting reestimate when requirements change) have made it not particularly viable as a product.

Finding a balance of power and simplicity is never easy.

I'm a consultant, and it happens that hardly any of my clients use Jira. So this is the result of scratching my itch (and the itch of people who already give me money) first, and dressing up the result for others to use.

Lots of people have expressed interest in Jira integration, and that's definitely on my list to accomplish one way or another. The Atlassian marketplace is like most app stores, though -- if people already know your name, it's easy for them to find and install your app. But if you're a relative nobody, there are 50 other estimation apps, and very little room to pitch what makes you unique.

I believe we're back up. Thanks for your patience.

Yep, it's down. Y'all have just about tipped over my baby redis instance with a few thousand project simulations all at once. Should be back as soon as I scale 'er up.

It's not better; it's almost exactly that, as detailed in many comments below. I choose slightly different thresholds -- 75% is not very high, you'll be wrong one time in 4 -- but that's the approach.

If you're already doing log normal modeling of your estimates, and including sick days, social loafing, etc, then you don't need Vistimo Quotes. Just keep doing what you're doing!

Haha, you're fine! It's pretty much just me behind the curtain.

(And honestly, sometimes I worry the UI is too slick -- that it will give people expectations the tool won't live up to.

But I have too much fun making fancy buttons, I can't bear to get rid of 'em :) )

Vistimo (the full version at https://www.vistimo.com) does too.

It turns out the project management space is full of neat tools with clever abilities, but it's very hard for a team to switch between those tools. It's expensive and time consuming!

Vistimo Quotes is an attempt to pull just statistical estimation out on its own, so you can use it no matter what you use for your project management.

(A note: this and EBS are pretty different in their actual math -- they just seem similar because the next closest thing is "everyone agrees on a single number per task and we add them up" which is so limiting that just having a statistical model puts EBS, 50/90, and monte-carlo into their own category.)

About 5 years ago, when I first started using this method, I gave a talk about it that went into detail about how to do it, and the benefits. I did a live demo showing how well it modeled the variance even for really simple tasks like "take off your shoes and then put them back on".

The audience reaction was very positive, and I was pleased to have spread the word.

No one actually put it into action, though. It turns out if you need better estimation tools, you don't have time to make them -- you're in crunch time, because your estimates were bad.

The benefit is not so much slick UI -- that part is just me having fun. The benefit is that the work, however easy, is done.

If folks "steal" this idea because it's easy to implement, that's great! It's not a new idea, just an underused one. I just want to stop being hired onto contracts where the first thing I have to do is explain that the deadline is impossible.

I agree with you that a linear backlog is not sufficient to do really sophisticated planning -- Vistimo Quotes is a pared-down tool designed for easy adoption, because my kitchen-sink version requires too much buy-in for many teams.