
Hyperproductive development - mmphosis
http://blog.jessitron.com/2017/06/the-most-productive-circumstances-for.html
======
ekiminmo
I have had the opportunity to both design a complex application from scratch
as the sole developer and to be thrown into a complex system developed by
someone else (who had since left the company). I have found the same truth:
being the original developer makes you 10x (or more) productive than anyone
else. It takes a lot of effort to bring anyone else up to that level and it
will slow you down as you try. What makes perfect sense to you as the original
developer will rarely make sense to anyone else, and understanding is critical
to making changes.

Being a 10x developer is always situational. You have to be 10x faster than
someone, and that difference in speed should not be attributed to "natural
talent" when clear organisational issues already exist to explain it.

~~~
douche
Having the entire design of a system in your head is invaluable. I'm in that
situation with one of the products I work on. It can be frustrating, at times,
when there is more to do than one person can handle, and you have to delegate
tasks out, so you end up spending much more time explaining how something
works and guiding someone else as to how to implement a feature, than it would
to just go in and make the necessary changes. Eventually, it does pay off, but
it requires constant effort to keep abreast of the changes and document
everything.

------
0xbear
Just partition work and make your team members experts in their own areas,
while requiring that they explain what they do and why, and have them review
each other's PRs. That's how I run things. I don't know where the author of
this article works, but we can't afford to "like seriously slow down". I'd
rather figure out a way for us to further speed up without working any harder.
Loose partitioning is one thing that helps with that.

~~~
thetmkay
Could you explain how you get around the knowledge silo problem? Fungibility
across the team is useful for resource allocation and can prevent bottlenecks
- for example if a part of the codebase is higher priority or someone is ill
or on holiday.

Loose partitioning seems like it would work if either:

1\. the partitions were similar/simple enough for other members to grok easily
2\. the documentation and code sharing were thorough and extensive

I don't know how feasible it is to rely on (1) and (2) seems like it would
cost an investment in time that would subtract from the efficiency gains of
partioning. If it is (2) what are the exact reqs/mechanics for docs/PRs that
seem to have worked?

I'm especially curious as "how to structure development teams" is something I
am beginning to actively learn about.

~~~
jfoutz
> Could you explain how you get around the knowledge silo problem?

IMHO, you can't. Imagine either extreme. In one case, everything is so well
documented and test, and every developer has all of the necessary domain
knowledge for every problem. In the other case, everyone is hyper specialized,
and hasn't the foggiest idea what's happening on the other side of the
interface they're calling.

The reality is, some people like small, diverse problems, and want to make
small-ish changes over a big codebase. Some people like big, deep, gnarly
problems. Furthermore most people vary from week in their productivity and
quality.

It's a puzzle. each person is a tile, and you have to cover the whole problem
with tiles. As people produce solutions, you have to consider, how much of the
codebase could be handled by your most jr developer. Does the code need to be
so simple anyone can work on it? Generally, yes, but not universally. There
can be some scary parts of the code where, perhaps only half the team can be
trusted to mess with it. The thing that sucks, is when you have a scary corner
of the code that only one person can handle.

Both extremes suck. Be judicious about how much scary code you're willing to
tolerate. All i can really offer is hand wavy advice. I don't have a formula,
and i kind of think a formula can't exist, because there are so many
constantly changing factors. Time pressure, turnover, inconsistency, changing
needs, there's just a ton.

Trying to match people with stuff they like to work on, and not being afraid
to pull people back when they start getting a little too clever seems like the
best heuristic.

~~~
wiz21c
I like this answer. I'd say it differently : provided you work on some non-
genius-level code like your average (no disrespect!) website, the problem will
be more human than technical. Figuring who's good at what is quite connected
to who likes to do what and how they want to do it (small fixes, small
projects, long projects,...). Some people are super good at coding batches but
will just stop working if they have to interact with a non-cooperative person
(say, a customer). Other will do marvel at understanding one's need but will
make very approximate code. Some will like to review someone else's code but
will hate to be reviewed. Some will need constant attention or else they'll
drift to facebook, youtube, whatever.

Managing people is so much more about soft skills than technical ones. I've
managed people who learned to code alone, people who learned at college, or
university level, up to phD. Each of them is different.

The only thing I don't know how to do is : how to motivate people who work-
for-eat, who are not passionnated about their job. I have no idea and it
drains a lot of my energy :-(

------
majewsky
Modularization helps massively. I recently designed and built a new
application, which consists of a core part and a number of modules which all
have a very small interface to the core. I then strategically brought in
colleagues to implement these modules while I focused on implementing the core
logic and its extensive test suite. Also, documentation, documentation,
documentation. I made three different documentations: one for users, one for
admins (how to deploy the stuff) and one for developers (how the code is
structured and how you can spin up a development environment).

------
GoToRO
So the real problem is that the system is not divided in small and independent
chunks of code. Or, we didn't hire an achitect. Or, we just fixed all the
small things without any consideration of how they affect the whole system.
Somethimes a small change is just that, a small change. Often times a small
change requires you to rethink the architecture of the application. Excep you
don't receive the time needed because "it's just a small change".

