
Ask HN: What company environment has enabled your best work? - g10r
Interested in specifics around team dynamics, communication, learning, decision making, physical layout, etc.
======
temporallobe
My first software engineering job was with a big aerospace company about 20
years ago. Back then, budgets were big and the culture was completely
different. Even the lowest peon had a huge cubicle with lots of desk space and
privacy. Standups were not a thing and Agile wasn’t on the radar. We had lots
of time to do anything we were assigned and never had to do much reporting
aside from weekly meetings. We all had a general sense of schedule but it
wasn’t rushed at all. We also didn’t have rhe always-in communication tools
like Slack. Phone calls and face-to-face were it. This all made for a very
relaxed environment where no one felt rushed and we had time and space to
contemplate and concentrate. This is where I learned and created the most. I
basically taught myself Perl, Unix (we had SPARC x-terms), Java, bash, csh,
ksh, SQL, Javascript and web application development, and so much more, all of
which I still remember to this day. I was happy and relaxed and pretty much
always looked forward to learning and exploring more every day. Clearly this
type of environment works well for some people, and it certainly did for me. I
credit these early years to my success. Fast forward 20 years and I am in a
completely different environment - open office plans that encourage
collaboration but also distraction, Agile tools that promote micro-management
down to the number of minutes you spend on a task, daily stand-ups (sometimes
multiple per day if you’re involved in several projects), and constant
reporting to management, SCRUM masters and POs. Oh and chat tools. These
constant interruptions often make it impossible to truly do creative and
deeply thoughtful work. Most of what I do is rushed and measured and we are
always analyzing what we can more efficiently and quickly. Responsiveness to
messages are also scrutinized. Oh and all the meetings - Sprint planning,
retrospectives, reciews, backlog grooming, etc. I estimate that most of what I
do these days is a lot of administrative busy work and useless overhead, which
is definitely not conducive to doing what I believe I do best - write code.

~~~
henrik_w
Here is a counterpoint. I worked with software development at Ericsson for
about 10 years before XP and agile came out. I too had a private office, and I
recognize a lot of what you describe. While it was nice, it was not a very
productive environment. Each release of new SW was enormous and typically took
a year or more to get out. The developers had no real idea of how things
worked in production. Lots of useless documentation was produced. Later on,
RUP and tools like Rational Rose were introduced that made things worse.
Basically, things worked out despite the process and tools, not thanks to
them.

In all my jobs since, I have worked in a more agile setting. By that I mean
that the team is small (less than 10 people) and sits together with some sort
of product owner. Not private offices, but rooms where only people working on
the same thing sit. Frequent releases, fast feedback. Very few meetings, most
issues can be worked out in the team. In my view, this is a quiet environment,
but occasionally there are dicsussions that you overhear (but that is not a
problem). In these types of environments I have been much more productive than
I was at Ericsson.

~~~
danmaz74
What you describe looks how agile was supposed to be. What the op described
looks like a perversion of agile perpetrated by managers who either don't
understand why agile was born, or do understand it, but only care about
increasing their power instead of getting things done.

~~~
henrik_w
I know. When I first read the XP book by Kent Beck it was a revelation. That
was the first time I saw a methodology that I felt worked and agreed with my
own experience. Planning everything out in advance is hopeless.

There are two great quotes that I think capture this:

“A complex system that works is invariably found to have evolved from a simple
system that worked.” John Gall

“Enlightened trial and error outperforms the planning of flawless intellects.”
David Kelley

It is really sad to read about how often the agile ideas have been misused!

~~~
fhbdukfrh
How about "a team of skilled developers is likely to be successful with any
software development approach; an inexperienced or untalented team is doomed
regardless of the chosen methodology"

After 20 years that's been my experience

~~~
josho
Yes. But unfortunately not every team can be made entirely of rockstars. So
the purpose of a methodology is to increase the probability of success for a
moderately talented team.

------
aantix
A top-notch VP of Engineering who knew when and how to reduce scope (because
he was an active contributor to the code base) and was also one of the best
coders in the room.

1) Pair programming, with the VP stopping by every couple of days asking
"where are you guys stuck" and would actively try to solve our problem.

2) Story prioritization - each PM would write product stories for the backlog
in an effort to get them in the next sprint. The same VP (above) would review
each of those stories in front of the PMs and developers. If it were really
lazily written, the PM was shamed, it was thrown out, and could be resubmitted
for the next week. Developers got to ask questions, add tidbits regarding
prior work that may need to be studied to complete the story.

3) If a bug made it out in the release, it was no-one's fault. Everyone worked
as quickly as possible to either create a patch or roll back the feature
completely.

P.S. That VP of Engineering is Andres Camacho. He's in San Francisco. And he's
amazing. Work with him if you have a chance. He's well known for hiring Jr
developers, training them via pairing with them intensively, getting them up
to speed quickly and having them contribute meaningful code within a few days.
He's now the CTO of Better Therapeutics.

~~~
rammy1234
"the PM was shamed, " this does not sound right. does it ? why to shame,
ignore it and move on. shaming has to be a private affair not public.

~~~
rahimnathwani
I'm a PM and didn't have any negative feeling when I read that part of the
comment. I was reflecting a bit on why. I think it's three things:

1\. If I've not done my job as a PM, then it's _much_ better to figure it out
earlier rather than later. If engineers struggle on without the right support
from a PM (whether that's stories/requirements, oral clarification, ...) then
that can slow things down or create worse outcomes. So I'd rather someone call
out holes in my work at the earliest possible opportunity, then be polite so
the problem can get larger.

2\. In a high trust environment, people can take criticism of their work
without taking it personally. It's hard to achieve this type of relationship
(with specific people) or environment (with a group of people), but can make
things much smoother.

3\. I feel the job of the PM is to make the team successful through whatever
means possible. Feedback/criticism directed at me is a valuable source of
information to support that, whether or not I am the correct target.

~~~
rammy1234
shaming is not criticism. criticism is an expression of disapproval of an idea
not the person. But shaming is personal. This is not constructive to improve.

~~~
rahimnathwani
You are, of course, correct.

But people often choose whether or not to take something personally, and their
reaction determines the outcome. Consider the following situations:

A. (Bad case) You criticise my idea/proposal, and I interpret that as you
criticising/shaming/blaming me (i.e. I take it personally). I then decide to
ignore your criticism, because I feel it is based on your personal opinion of
me, which I know is incorrect.

B. (Better case) You criticise me personally (e.g. "you're a bad PM, as
evidenced by X"), and I take it dispassionately, trying to understand why you
feel that way, use that to inform my understanding of the situation, and find
a way to make things better.

In A, my idea was criticised, and there was no positive outcome.

In B, I was personally shamed, but there was a positive outcome.

I cannot change how people communicate (at least in the short term) but I can
change how I react, and hence what impact I have on the outcome.

~~~
rammy1234
people reacting to situations is about individual. but we know every
individual is unique and different. Team should be encompassing and not
assuming. CEO or Project Director's boundary is only with the idea and not the
individual.

Idea can be criticised, never individual. Your argument may sound right, but
it is not considering everyone. Your argument is saying how one should react,
but is not answering what if one reacts differently. How can we mend it.

Leader is one who is compassionate and has ability to differentiate idea from
individual. Work is not entirety. Idea will never define a person. whenever we
critique, it is best to keep it till the idea and never to person. my few
cents.

~~~
rahimnathwani
As I said before, you are correct :)

And I always aim to criticise the work/behaviour and not the person.

However:

\- When I criticise a piece of work, someone can still choose to interpret it
as shaming or a personal attack.

\- When someone criticises me personally, I can still choose to focus on the
useful part. I don't _have_ to feel offended/upset.

~~~
rammy1234
When I criticise a piece of work, someone can still choose to interpret it as
shaming or a personal attack. \-- yes agree. this is not the mistake of the
person commenting.

When someone criticises me personally, I can still choose to focus on the
useful part. I don't have to feel offended/upset.

\- This as mentioned before, this we cannot make a rule but a guidance but
this is very personal to the individual and most inidividual even if he is not
offended, will not work under him for a long time to come. which is not good
either way.

------
mikelevins
Looking back over thirty years, and picking out the projects where I think
I've done the best work for the greatest lengths of time, the common
characteristics seem to be a quiet working environment, a high level of
confidence and trust among the people working together (together with a level
of competence that justifies it), clearly-communicated objectives, and
substantial freedom to choose how to achieve those objectives.

I saw good situations in a couple of large companies, but also in some small
startups. Private offices or common offices for small teams (2-4 people) with
sound barriers to keep things quiet were the best physical environments. My
experience with remote work has been uniformly good.

The best psychological environments were ones in which teams developed
confidence and trust in each others' capabilities and judgments, and in which
leadership was trusted both to make reasonable strategic decisions, and to
treat people fairly.

I've also seen a variety of bad situations. Major contributors to loss of
productivity include excessive noise and distraction in the workplace, too
many interruptions, oppressive micromanagement, loss of trust and confidence
among colleagues or in leadership, too much or too little process, anxiety
over the solvency of the company, infighting and factionalism, sudden,
frequent changes in product objectives and business strategies, loss of
leaders' credibility, and sketchy business practices. All of these things
impair productivity.

~~~
bergerjac
I'm a former software engineer where noise and distractions used to bother me
to NO end.. someone dropping a pin would make me cringe with frustration

5 minutes in a noisy sales office with 17 people and it all went away.. the
brain adapts quickly..

I know building software is different though.. constructing an entire
blueprint in the brain.. it takes focus.

One of my biggest mistakes is I rarely drew things out. If I ever went back to
software, I would draw out the system, its parts, and each of the tasks/mini-
projects before getting started

~~~
solarkraft
Do you have tips on drawing things out? I feel like I need to draw some things
out, but haven't yet found a good system for it.

------
redleggedfrog
No company at all.

My best work I've done between 5:30AM and 7:00AM on my home machine before I
got ready for work. The code I have created there runs hundreds of websites
and causes me less than 5 trouble tickets a year.

My home computer sits in a mud room full of boots and heavy coats where no one
bothers me first thing in the morning. It's a littler cooler than the house. I
drink tea and espresso. There is no phone, or IM, or anything too distracting
(the occasional woodpecker on the gutters).

My home computer is from 2009, only the video-card is upgraded. I run Windows
7. I take a long time and tinker to figure out how things are going to work.
No rush. I build logging and error handling first, then functionality. No
users requests or specs from management. No influence on direction from
management. Management gets (mostly) finished code. In every case so far they
didn't know what I was doing and I presented the solution once I felt it was
solid.

Somehow I get away with writing no documentation.

I target good. Perfect is truly the enemy of the good. I write code I can hand
to juniors with a hour or two of explanation or that seniors can pick up and
use and ask minimal questions. No rocket science. This has made it so I don't
have to support developers, either.

My one mistake, or maybe, regret, is writing things for me then giving to my
employer for free (I do take company time to integrate it into the stack).
These solutions have made my professional life invaluably better, but I
sometimes wonder if if there was money to be made. But then, I have enough
money to live okay, so I'm not too worried about past opportunities lost.

~~~
simook
Your future self might appreciate just a little documentation. I recently
learned that lesson after taking a year off from side projects. I’m currently
having to retrace my steps because I no longer remember any details.

~~~
redleggedfrog
You're right on this, of course. I should make myself do it. One thing that
helps is I'm an inveterate commenter. Sometimes big blocks on the beginning of
a class as well. That helps a bit in remembering how things work years later.
Cause most definitely it is _not_ in my brain anymore.

------
noir_lord
My current one.

I work as the only dev for a small manufacturing company.

I work alone, in a big quiet office with nice hardware, a comfortable desk and
I get to choose all technical choices and set dev priorities.

My boss is ridiculously smart (hard science background) and trusts me to do
what I’m good at while he does what he’s good at.

I work 9-5 every day.

It’s basically programmer heaven.

~~~
kortilla
9-5 absolutely kills me. Is that by choice or because that’s what everyone
else does?

When programming I can do my best work with big 10-12 hour sprints when the
mood strikes and maybe a couple in a row. Then there are days with meetings or
days waiting for QA or other feedback where the right thing is literally to
just go home for the day at lunch time.

My best environment is where I’m treated like an adult with responsibilities
to deliver software and communicate when I have issues. My worst is one where
I’m treated like a child that must show up at certain times and provide
constant updates to the adults so they can be sure I’m working.

~~~
speedplane
I entirely agree that general standards of productive time are not at all
productive with many people. But the problem isn't just the time of day people
work, it's the compensation they receive for it.

If you're told to build X, you might do it in a day, a week, or a month, many
companies or managers wouldn't be able to tell what was appropriate. On the
other hand, if you were told that you would receive Y percent of revenue of
product X for the next three years, your incentives would totally change. You
would be incentivized to work as efficiently as possible. More than just
money, you would have an increased level of ownership in your own production,
which would build confidence and value over the product you build.

~~~
noir_lord
For me it's the freedom to set my own priorities, tell me what you want and
I'll build it.

As for a sense of ownership, not a problem when you're the only dev.

I own everything that isn't the windows server and desktops.

All the Linux servers, the network, the android terminals the production
software, driver terminals etc are all my responsibility.

~~~
speedplane
If you're an employee, you actually own nothing. To own it, you need to put
some skin in the game, feel the burn when things fail and share in the bounty
when it succeeds. A "feeling" of responsibility, is one thing. But having your
bottom line decrease when you mess up "feels" quite different.

~~~
noir_lord
> As for a sense of ownership

Note the word _sense_ , clarifying is fine but why be needlessly pedantic.

------
theengway
My most joyful (work wise), efficient and productive 5 weeks ever were: * in a
remote place, visiting and living with my grandparents * in a village with
little civilization but tons of nature around * when for a break I could just
go outside house, hike around the barn, watch village folks going about their
business in the farm or around the kettle * with big time zone difference from
the rest of the team that allowed only occasionally for 1 hour of overlap to
sync up * with my wife being away for her studies in a different country (told
ya it was joyful only work-wise!!) with fixed limited hour to catch up on a
phone.

In those 5 weeks I’ve built the major part of the scalable distributed OLAP
Cube that had proved to be very simple, robust and reliable and was still in
use to support telemetry of over hundred of customers after 5 years.

The biggest distractions were a cat, incredibly beautiful rain showers, and
warmest ever discussions at the dinner table.

~~~
kendallpark
During med school I would ride my bike on a scenic trail to a campsite on a
bluff overlooking a massive river. There was a camp store with snacks and
beverages and a Thai restaurant served out of a trailer. The campsite had a
bonfire and featured live musicians in the evening. I only had a couple bars
of internet through my phone.

Never had more productive study sessions in my life. 1 hour bike there
(listening to lectures on my phone) + several hours studying at a picnic
table, eating Thai food + 1 hour bike back (w/ audio lectures).

I think there's something special about the combination of being 1) in a small
community, 2) relatively disconnected from rest of the world, 3) surrounded by
natural beauty.

I've never been able to replicate that environment since. I've read a lot
about summer shifts on the Antarctic bases--sounds idyllic for the same
reasons as above.

~~~
kornish
Sounds wonderful. Where did you go to med school?

~~~
kendallpark
Mizzou! (University of Missouri)

------
jl2718
I worked at a national laboratory. There were 125 staff to one group leader
and one assistant group leader, and they had their own projects too. Everybody
who worked together was in the same hallway. Real offices, two people each.
Zero remote. Core hours. Gym, cafe, and doctor on site. There were no
meetings, just presentations you could go to. I didn’t use my calendar.
Project matching was a natural process; you just had to report a rough
fraction of time for each thing you were working on. Performance conversations
1:1 once a quarter with group leader based on feedback collected from project
leads. 1-page writeup once a year. Projects always require senior staff to
work with junior staff. Constant in-house education in scientific computing.
Full access to journals and site licenses for just about any software. In
general, you knew everybody that controlled any resource you might want access
to.

Really didn’t value that place enough.

~~~
Infernal
Now I’m really curious which national laboratory, though I’m guessing if you
were comfortable saying you would’ve done so.

------
ozmbie
At a studio I worked at once, two others and myself were assigned to a new
project. Since we were the only ones working on the project, we got permission
to clear out a storage room and convert it into an office.

It was just the three of us in a decent sized room and I feel that my work
satisfaction and productivity was double what it was anywhere else in the open
plan office space. There were very few distractions, but our office was open-
door and just off a commonly used hallway so we weren’t hiding. We had enough
space for a whiteboard and a 4th desk that we used for reviewing work
together.

A few months later one of the managers saw what we’d done and decided he
wanted it for his personal office. We went back to open plan :(

~~~
quickthrower2
That’s where you 3 team up and resign together and join another company as a
well oiled threesome.

~~~
chestervonwinch
> a well oiled threesome

Tobias Funke, is that you?

------
bryanrasmussen
I don't think it is so much any of those things that enable your best work, it
is having a problem that requires innovation, in a company that allows
innovation (probably because it will die without it, so a startup), and where
the skills required are especially suited to you.

That said probably the companies that provoked my best work where ones that

1\. I had a personal investment in

2\. There were parts of what we worked on that I found intellectually
interesting.

2\. had small teams and we were not afraid to argue for days about how to do
something, and arguments were clear.

3\. technical people that worked together sat together.

The places I did my worst work

1\. Hated the concept and what we were doing.

2\. Just cashing a paycheck (I have also done good work just cashing a
paycheck so not sure how important it is)

3\. Even if the teams were small the tasks the team handled were split up in
such a way that nobody really had any input on anybody else's area.

4\. Argument just did not make any headway on anything. If someone had more
power in an area you let them have their way because it was a waste of time
saying anything.

5\. if you sat with the people you worked with it was almost an afterthought.

~~~
bryanrasmussen
hmm, also my best work was obviously provoked by situations where I didn't
need to follow a traditional western counting scheme.

------
auslegung
XP: open office, promiscuous pairing, very little remote work, 4-6 teammates,
2-3 30-minute breaks throughout the day to do whatever, regular lunch n
learns, honest retrospectives, continuous deployment, powerful tools (Haskell,
Elm, postgresql), daily company-wise “standup” with 70 people that averages
5-10 minutes, bi-monthly team get-togethers to play games and watch movies,
regular lunches together, good code review practices, entire team constantly
striving to improve.

Software engineers somewhat involved with most relevant business decisions. We
are empowered to respectfully question decisions.

~~~
scarface74
Some of that sounds like a nightmare to me.

\- open office - impossible to concentrate.

\- constant pair programming - ughhh

\- I have a family and friends outside of work. I’ve gone out of my way not to
mix my work life and personal life. I have no desire to “play games” and
“watch movies” with my coworkers. I come to work to work. I have friends who
are _former_ coworkers.

\- regular lunches together - again, my lunch time is my time to get away from
the office and recharge.

~~~
thoman23
Seconded! You could be my work best friend and years after we've moved on we
could still enjoy not talking to each other.

------
restlessdesign
This was before we grew to 200+, but the best snapshot was:

\- <80 person team (total); ~60% engineers

\- 0 product managers: design and engineering are equally empowered to make
the site nice within general business/product definitions defined by GM who
would constantly get excited about the work you showed her, making you feel
good about yourself and your work

\- 0 project managers: business understands that there is no magic formula for
delivering products that haven't been built yet and so long as we try our best
to hit dates and cut scope as needed, it's on us to track our progress and
determine priorities

\- gm, cto, and head of hr all supportive of growing team and individual
members in a non-political way

\- politically-driven employees (typically a head of sales or marketing) shut
down and churn out quickly

\- engineers talk directly with customer service

\- engineers perform rounds helping out in support forums

\- domain specialists, but no fences. i might be a web engineer, but if
there's a sql query i feel compelled to optimize, nobody is going to stop me.

\- company regularly interacts with, and hosts local events for, an engaged
user base. engineers actually end up having in person conversations with our
users, gathering honest feedback for improvements while simultaneously being
told how great the product they contribute to is overall

\- relaxed hours ("you're an adult; we trust you to get your work done")

\- when dining out or getting drinks, even paying by cash a large group is
able to come up with the right amount of money, with no one person needing to
chip in more than necessary

\- anyone in the company can deploy the site with a single chat room command

~~~
muzani
I'm very surprised you could have no managers. Personally I always thought it
wad good to have a management level person to filter out content from
customers or Product.

~~~
aylmao
One of my most productive sprints I ever had at a job was after a couple
months working on an internal tool that was going nowhere. After being
frustrated for a long time with a project's management, I cut the middle-man
and went directly to the customer, did my own user research, brainstormed
either on my own or independently with others, and kept direct contact with
the users to keep a tight feedback loop when shipping features.

Management and middlemen can as much help velocity as they can hurt it. More
hands doesn't always mean faster work ¯\\_(ツ)_/¯

~~~
Aeolun
I think the problem is the middlemen feel compelled to add value somehow,
since otherwise people would figure out that their job is pointless.

~~~
shandor
The adage "good leaders make themselves unnecessary" applies.

If you have people under you, or can coach your people to take parts of your
responsibilities off you, I think that's a great outcome. If your ICs are so
good that they can actually do that, you should give them a raise and be glad
you get to focus on other things in the meanwhile.

Of course, if the manager is unable to then broader their own scope, they
indeed become disposable.

~~~
Aeolun
Oh certainly. There are a lot of managers that add value. I was talking more
about the 5 layers of confusion (product manager, project manager, business
manager, business architect, designer) that exist between our customer and the
developers. There may be more that I haven’t yet discovered.

We recently spent quite a while on developing a feature only to find out the
customer didn’t actually want it.

~~~
shandor
Ouch. Sounds like your product manager and business manager are indeed not
doing much more than warming their seats :)

------
xivzgrev
My current one. The company treats people like...well people. -transparent
communication -soliciting feedback often -an ethos of "take care of yourself,
your family, then the company", manifesting in flexible WFH situations -lots
of investment in personal development / growth -an emphasis on bridging gaps /
empathizing / assuming positive intent in working with others

At pretty much every other company I've ever worked at, I've always felt that
if I inconvenienced the company at all, it basically wasn't going to happen
unless I brought a strong business case. Company always came first. Conversely
here, I feel like it's a balance. If I want to do X, my manager / others will
make an effort to find a business need that matches that. There's a very
generous (paid) maternity leave policy.

When you like your manager and you feel like your interests are aligned with
the company's, and you feel like it's a little more relational, that's when I
do my best work. I've been looking for this for a long time, and I'm thrilled
to be here.

~~~
travis86
Your company sounds like somewhere I'd like to work. If you are comfortable
with it, could you email me the name? My email address is in my profile.

------
Fradow
One of the main game changer for me has been having a great Product Manager. I
went a lot of time with not-stellar PMs, and some time with no PM at all, and
having a new PM who is great at his job lately have made a huge difference.

What's so great about this PM? (I won't try to generalize, I'm too
inexperienced for generalizations)

\- he doesn't code, yet he listens to our expertise and act on it

\- he doesn't half-ass features, he takes the time to reach out to customers
and prototype

\- he shields us from upper management

\- he respects our time, and actively prevent outside interruptions

\- he is careful about when we get blocked/slower, yet he doesn't try to
micro-manage

\- he doesn't balk away from the boring and ungrateful work

Despite having no say in his recruitment, I am glad my company decided to get
him on-board (despite no previous formal PM job)

------
kerneltime
When I had a visual shield between my screen and people walking around.

When there is enough space that some one else's conversations did not cut
through my headphones which do not play music by just cancel noise.

When what is the problem is articulated well (I do not mean details for a
task, I am ok with a problem with no known solution but there needs to be a
common articulation of success..)

When my co-workers are emotionally secure enough to have a discussion where
any and every idea is open for a challenge. I hate to say this but "disagree
but commit" is a good mantra as long as "disagreement" is not used against
you, actively or passively. I burn more energy navigating my path around egg
shells and consequently have less for what I need to do.

------
westoque
We are 100% remote with an optional co-working space that is available if you
ever want to work at an “office” environment.

Project is managed mostly through airtable with quarterly goals with weekly’s
and daily’s (not standup) to check on progress. Then we have a company/team
wide call every tues for the weekly brief.

All the above enabled me to have the best environment by then investing in my
home office. A space that has a good desk (multitable sit/stand), chair
(aeron), and good lighting, not to mention a beautiful machine (iMac Pro).

The issues that followed were more of the focus issues when doing work at
home, so I got a pomodoro clock which then made everything seamless.

------
lykr0n
I guess this depends on the person, but for me- My boss 100% hands off on my
day to day work.

I can chose what I work on for the day, week, month, or Quarter. I have my
work area, but within that I have 100% freedom to figure out what I need to
do- the only thing I need to do is to be able to justify it. I can select the
tickets I want to work on, areas to improve, initiatives to take up, or
software to build.

Also, the core business drive of measuring and qualitating your work. So, you
can see the impact you are having on the business (positive or negative- NOT
in a way that affects your job, but in a way that you can say "I did X which
made Y faster, causing a 3% growth in click-though rates).

But I do wish I had a more private workplace. Hexes are better then the
nightmare of open offices, and I work on a quiet floor, but sometimes I wish I
had a door I could close.

~~~
g10r
Funny enough I've been obsessing over this concept of "aligning vectors" /
measuring the impact of personal KPIs against the total progress of a
business.

“Every person in your company is a vector. Your progress is determined by the
sum of all vectors.” — Elon Musk

~~~
lykr0n
It's quite nice to see the positive impact you have on the rest of the
business. It gives value to what you do day to day. Where I work is very data
driven, so any chance can be measured if you know how to look

------
bsenftner
Amazing it has been this long: back in '91 I was working for Philips during
the development heyday of CD-ROMs. I was in the CD-I division, basically CD-
ROMs with a special file format for streaming media. A Dutch executive was
sent to the States to "show the yanks how to produce" because that division
had only managed to pull off production disasters to date. Of course, the
American management wanted this guy to fail, so he was assigned a tiny team of
1 staff developer (me) a medium skilled contract developer, two graphic
artists, and two production assistants. We were all recent hires, and were
given 30-days to produce a product that all other productions were typically
given a year. This Dutch guy was a gift from heaven. He collected us into a
small office suite, with programming, art, and editing each in separate rooms
of two, a shared space each opened into, and best of all, people had to travel
through his office to get to us, so people could not bother us without his
knowledge. But the real key to his management style was an idea he called
"interfaces": he believed people did their best work when free, but working
towards a well defined interface that their work hands off to the next person
in a production flow. As long as you respect the needs of the people before
and after you in the work flow, everything goes smooth. And that is
accomplished by teaching those before and after you the importance of your
work and why it is critical to the projects flow. This idea sounds simplistic,
but it embeds "care of process" where, and only where, it is required.
Needless to say, our 30-day deadline was met, the production team went on to
create a fairly big award winning series of "Ken Burns style" documentaries,
and that Dutch executive graduated to become the CEO of global Philips: J.P.
Isbouts.

------
01100011
Working from home as a contractor on a team of two making a conditional access
system from scratch. No bullshit, no politics. Just code and happy customers.
I wrote complex software all by myself which worked nearly perfect and
continues to serve hundreds of thousands (probably more now) of digital cable
subscribers. My friend/co-worker/architect did a great job with his stuff and
mediated the boss's crazy whims.

I'm still owed $14k for my work, which I'll probably never see, but I'm proud
of the work I did. It gave me something to talk about in interviews and
probably made me more money than I'm owed.

------
ninjakeyboard
I don't want to be managed. Tell me the objective and give me the freedom to
meet it for you. I'm smart. You don't hire smart people and tell them what to
do. You hire smart people and let them tell you what to do.

------
natoliniak
\- allow flexibility to work from home

\- those who like open office can sit together, but for the rest, provide a
semi-isolated quiet/dark area to concentrate in and a whiteboard.

\- plenty of conference rooms.

\- if expecting to work with new tech/framework, allow reasonable time to
learn during work hours. \- allow time for documenting

\- allocate time for fixing tech debt every sprint

\- provide training on the product being built

\- give good insight into product decisions

\- if unexpected work has to be added mid-sprint, pull something else out!

\- acknowledged that when someone worked all weekend to finish something that
they get a bonus day off some other time

\- keep process meetings to minimum

\- when a developer brings up a security flaw, take him/her seriously

~~~
ironchef
One slight alternative which I've had in the past was instead of debt pay down
every sprint, it was every N sprints, we'd have a pay down sprint.

------
adverbly
I think my answer here is a bit different from most, and that might have to do
with a different definition of "enabled". Yes, I _do_ my best work in an
isolated, quiet, focused environment. However, I would say that this work was
actually _enabled_ in a different environment- and that is the environment
where I got to pair program with an existing expert in a system. The amount
that I learned - both in breadth and in depth from these sessions - has
accelerated my learning enough that I would say that I would have been unable
to perform my best work without that assistance.

This environment requires that both participants have plenty of humility,
openness, and patience, but when it works, it can be priceless.

MPJ has a long, but relevant video on this:
[https://www.youtube.com/watch?v=qe1ZAy2yNvE](https://www.youtube.com/watch?v=qe1ZAy2yNvE)

------
kendallpark
At the macro (yearly) level I am most productive with:

1) condensed higher intensity blocks followed by larger breaks

2) distinct "seasons" of work that differ in projects/pace

At the micro (day-to-day) level:

3) no logging of hours

#1 and #2 are a product of the academic calendar. I find the regular 9-to-5
work week paradoxically draining. I'll trade a good chunk of my weekends and
evenings for longer breaks between "ON" periods.

As for #3, one company I worked for simply trusted that you'd put in your 40
hours a week. It was more flexible and quite simply _freeing_. If I were in a
good flow state I might work late to finish up a feature, then sleep in the
next morning (provided there were no meetings). All without the tedium of
counting quarter-hours.

------
peterwwillis
None? When I used to work in open source for fun, you could take all the time
in the world to develop the right solution. People communicated freely
remotely over irc and mailing lists. Very little red tape. Easy to feel like
you're actually contributing to something. You get to pick what you work on
and either clean up little things or tackle big projects. All necessary
information is public and easy to find by asking the group.

Really you just need fewer barriers to doing work, and to make it easier to
find and publish information. A group consensus or product owner can decide if
work gets merged or refactored.

------
towaway1138
The best work I ever did involved a large collection of computers admin'ed by
some serious f-ing idiots. They'd break that system in every conceivable way,
every day of the week. So, I ended up writing a seriously fault-tolerant piece
of software that could make forward progress on my users' problem no matter
what. It turned out to be glorious.

Not much beyond that, except that my users had a clear need, and I was given
time to do the work. Had a private office, but that mattered little.

My moral: Sometimes you really can make lemonade out of lemons. Maybe the
torrent of shit raining down on you is a gift sometimes.

------
intertextuality
Working from home, while having a 10 min daily standup voice call. I work with
colleagues but mostly on my own stuff, so I get a lot of freedom to handle
things.

~~~
chime
Same here. With the added bonus of selecting my own schedule. I have a 25-26hr
sleep cycle so it is very unproductive for me to be available at 9am or 11am
or any specific time daily. I also prefer to work longer hours late at night.
Thankfully everyone I work with as well as my wife/kid totally understand this
and accommodate my atypical hours.

The end result is I am extremely happy in my work hours and arrangement as
long as I don’t have early morning doctor appointments or something.

~~~
juststeve
A 26 hour sleep cycle sounds extreme.

~~~
chime
Yeah, it's not by choice though. It can really mess people up if they're not
aware of it. This NASA TED talk about time on Mars discusses how a different
cycle can affect others too:
[https://www.ted.com/talks/nagin_cox_what_time_is_it_on_mars](https://www.ted.com/talks/nagin_cox_what_time_is_it_on_mars)

Ever since I saw that video, I've worked hard to (1) make sure others aren't
negatively affected by my schedule (2) accept that until something brings me
back to a 24-hour cycle, I have to persisently keep working on (1). Every
other week I will go to bed at 10pm with my wife and wake up naturally at 5am
and she'll have a great day being coordinated with my schedule. But within a
week I'll be going to bed at 6am and waking up at 12-2pm. Every month or so I
will stay up 30-36hrs without even trying.

None of this is due to bad habits, lack of sunlight, or lack of exercise etc.
Doesn't matter what I do or don't do, my body just doesn't live in a 24-hour
world. So I've learned to let it do its thing and work/sleep/eat/play when I
feel like. Never been happier.

------
InclinedPlane
Honestly? When my bosses were on extended leave and I had little oversight and
could do whatever the hell I wanted. I got so much done.

------
benjiweber
[https://benjiweber.co.uk/blog/2015/04/17/modern-extreme-
prog...](https://benjiweber.co.uk/blog/2015/04/17/modern-extreme-programming/)
XP teams, with pair and mob programming. Spacious team areas with big TVs for
coding in pairs or mobs. 20% time for learning and to foster bottom-up
innovation [https://benjiweber.co.uk/blog/2018/01/29/gold-
cards/](https://benjiweber.co.uk/blog/2018/01/29/gold-cards/)

Worth noting all these practices can be done remotely too
[https://cucumber.io/blog/2018/06/20/inclusive-benefits-of-
mo...](https://cucumber.io/blog/2018/06/20/inclusive-benefits-of-mob-
programming)

Also notable what was absent. No synchronous blocking code reviews. No
branching at all, just continuous deployment of small, safe changes. No need
for standups or design meetings when mobbing. Estimates unnecessary when teams
become good at slicing things small.

------
avip
Well managed code reviews. I care little for open spaces, slacks or deadlines.
Code review done by peers with good faith and deep knowledge is the only thing
that moved the needle and forced me to rise up as a developer.

------
ww520
Small team, offices for developers, open door for free to walk in to chat,
close door for don't bother, lots of whiteboards, ah hoc discusson, weekly
team planning meeting on Monday, weekly release/resolution meeting on Thursday
after lunch, release and recovery from fuckup on Friday.

~~~
geoka9
Release Fri, recover from fuckup Sat/Sun?

~~~
ww520
Release in the morning. Whole day on Friday to recover in case of problem. If
nothing's wrong, the time is available to do extra stuff. Incentive for people
to get things right before deployment.

------
broth
I work in an open office environment. This is great for rapidly communicating
with co-workers and having people eavesdrop and chime in when necessary.
However, this can be a big impediment to productivity for some people.

What has worked for me to facilitate my best work is to reserve a meeting room
to myself for one or two hour slots during the week. This allows me to close
the door, put my back to the window and get focused. What's great about this
is this limits visual distractions, restricts uninvited visitors, and reduces
auditory distractions (I will usually wear headphones and listen to non-lyric
music).

Often I find that I will get more work done in this period of time than I
would if I was sitting at my desk.

------
mariojv
My best work was enabled by a work from home role with clear product goals but
wide latitude on on technical decision-making. The teams were active in good
code review, kept our chat channels from being silent all day, and were
confident enough in their abilities and trusted in others on the team enough
to ask for advice when needed. Technical decisions were largely left up to
whoever is doing the work, but major architectural changes would involve
either one person presenting a proposal for review or brainstorming sessions
with a small group.

------
balladeer
First one and a half years at my current company which was (maybe still is) a
startup but provided me with proper cubicles where I could concentrate and
work while also providing me with a process (or lack of it) startups often are
supposed to have that I could reach up to even CTO or CEO pretty much whenever
I wanted to. Or if I wanted to make some change or do something different or
new, I didn't have to go through a chain of command, I just used to meet with
whoever were the stakeholders with a short notice in a very casual to the
point short meeting or huddle. The place had nap rooms, gym, shower rooms
(which I used to use everyday because I would play 2 hours of badminton before
office), and people used to come there at 9-10am and leave by 5-6pm. It had a
separate hall for TT and foosball which were not used aggressively.

The new team however is a place which prides itself in having the "startup
culture". It's in a different building and it has TT and foosball tables
(pretty much never free) right next to our work desks which are like places
where everybody sits everywhere and I literally had to fight with people to
ensure that my "spot" remains "my" spot. People start coming at 11-130am and
keep leaving till 11pm - 12pm and you are often expected to stay back if
there's "dependency" and if you start pulling a 10-6 you are literally looked
down upon. This team loves to talk about working like this. Productivity is
hitting rock bottom. I know it turned into a rant but that's how I feel. Yes,
I am interviewing but only at MNCs :|

------
Niksko
I'm still figuring things out. Last job was at a big 4 consultancy doing CMS
work, current job is at ~1500 employee software company doing a mix mobile and
web dev.

Agile definitely feels better than waterfall, but it's also made me appreciate
why it goes wrong so easily. You have to be willing to experiment with your
process often, and retros have to have the ability to get brutal if things
aren't working.

Regular releases (every two weeks or so) are important. They help to reduce
scope creep and get you faster feedback. The trick is tweaking what a
'release' is. Having the ability to do targeted, beta or pilot releases helps
you get things out more quickly without scaring the rest of your users or
screwing up of there are bugs.

Pairing is useful, but there is a tendency in our team to say 'oh, there's not
many cards left in the current release, let me pair with you'. That's just
wasting time. Pairing should only be for knowledge sharing or speeding up
difficult code.

Slicing tasks is very hard. I think it's better if they're sliced vertically
(implementing a feature end to end) as opposed to horizontally (you write the
react, I'll write the API, and we'll meet in the middle). Horizontal slicing
leads to knowledge slios, implementation mix-ups and can also lead to very
small cards which means you're constantly context switching.

------
scarejunba
8 people in a basement. B2B product. Everyone in a room. I heard our technical
services person take the calls. "Do you see an Apple on the back?". Understood
the product through listening to our sales guys talk to people. There was a
fair bit of chatter and we just burned through ideas and stuff. Solid traction
and good growth.

Mmm-mmm. We grew past that, but that was the dream. Just sitting around a
table building product with great visibility into the customer's experience.
Gold.

------
jgimenez
Building my own company has been one of the most rewarding professional
experiences ever. Both Mobile Jazz (7 years old now) and Bugfender (3 years
old now) have accomplished to build a team of great engineers, but most
importantly great _people_. Together we build challenging products, be it our
own or for our customers. We care about what we do, we're able to learn from
each other, we have flexible schedule and location independence... what else
can I ask for?

------
BenMorganIO
My best experiences, as I think about it, tend to have these patterns:

\- No Slack for non remote

Slack is cool, but I remember thinking that if I needed to talk to someone,
it's over email or in-person. This really encouraged face to face or email
conversation. There was also Skype for remote workers, but if you're not doing
remote, you could kill Slack. Now that I think about it, Slack is more of a
vitamin than a pain killer for non-remote organizations. Slack is great for
remote though and love it.

\- No Agile

Ah, I remember when I had my first job using Agile. It was cool the first few
weeks and that was it. Again, it's not a pain killer, it's a vitamin. I had
the best time ever just sitting in meetings on Tuesday mornings to demo
everything in person then do code review with my CTO after. Talk with the
whole team including marketing on what we'd work on. I loved it. No agile, was
completely in the know and performing.

\- Support with Tools

It sucks not having the right tools to do the job. Receiving the appropriate
hardware, desk, and software has always been useful and makes me happy to come
into the office. It really sucks when you wake up, look at your amazing at
home desk, then go to a lousy work desk. Bling out the work desk. You can do
anything from getting a top end work computer, a great monitor, an eGPU (may
actually save a company money from AWS bills), a DAC/AMP (cause devs usually
have a thing for headphones and the budget for great ones), or a desk goes up
and down and has memory settings and it's fast.

\- Minimum Friction

If you get told you need to change up your landing page, change up the
tooling, or do a big refactor on something, always take it seriously. Some
people marry a concept or an ideal and it can often cause friction between the
team. Giving up the consistency and letting others use what best let's them
get their job done should be given time and thought. All in all: be fluid with
company practices and not letting a "mono-culture" take root is usually best.

My best experiences have been when a single employee can happily recommend a
new way that could radically change the initial experience of a customer or a
company culture. The fluidity maximized sales and development.

\- Wrap up

We have so much now with tools that can be categorized as pain killer or
vitamin. My best recommendation is to have less vitamins and more pain
killers.

Note: This is just me though. I know a lot of other people have different ways
they prefer to work. This is just me.

~~~
jacques_chester
> _I had the best time ever just sitting in meetings on Tuesday mornings to
> demo everything in person then do code review with my CTO after. Talk with
> the whole team including marketing on what we 'd work on. I loved it. No
> agile, was completely in the know and performing._

I know I'm discussing Scotsmen here, but: what about this is not agile?

~~~
ellius
There’s:

• Agile as a set of values

• Agile as a set of practices

• Agile as a faddish silver bullet marketed to people who don’t know any
better

I assume OP is thinking mainly of the latter two. It sounds like their
business avoided formal standups and sprint planning, and didn’t generally
care about Agile/Scrum etc. buzzwords. But I tend to agree with you that from
a values perspective that seems perfectly Agile.

~~~
jacques_chester
I think you're right.

Agile has a dirty name now, but it's well-deserved, because most folks have
had legitimately terrible experiences with stuff sailing under that banner.

I've had a legitimately awesome experience and I can't really use a different
word, because it either creates confusion or sounds like sneaky wordplay
and/or self-marketing hoopla.

I had a job where, due to the technology, I could not TDD. There was no sane
way to version control. No CI/CD, changes had to be made in dev and then
copied & pasted into prod. Before that I was in a job with pairing, TDD, CI/CD
and an avowed commitment to agile.

Of the two, the ostensibly-not-agile was more agile, because it hewed closer
to the values of talking to people and focusing on doing the most valuable
thing first. I would work on projects by myself. When I wanted to learn more
about my customers, I walked across the campus and talked to them. If I had
something I wanted them to give their opinion on, I would ring them and tell
them to take a look.

At the ostensibly-agile job we had a manager who talked to a middleman who
talked to a board of directors who heard from a line manager who talked to his
employees. It didn't matter how well we did the inner loop, because a lot of
the time we just produced beautifully-engineered diversions.

------
thenanyu
When I was an intern at Big Bank, I was literally put into the printer room.
Hardly anyone used the printer/copy machine so I was left alone in there for
the most part, other than my boss peeking in once in a while to make sure I
was still breathing. The door closed and there were no windows.

It was the most productive I've ever been. The code I wrote was mostly
garbage, but I got my reps in that summer and learned how to program.

------
patricius
When I compare the jobs I’ve had, I would say the first ever job I had as a
freelancer was best. It wasn’t for a particularly sexy, high-profile company
in the IT sector. It wasn’t a company that used particularly interesting
technology. It wasn’t a place with young, high-energy employees. But what I
really enjoyed was the opportunity to work independently as the sole
programmer on the particular project I was assigned to. I managed my own time,
decided how to structure my work and deliverables, and coordinated with domain
experts on my own. It wasn’t until I finished that project and moved on to
another with a larger (over-staffed) team, a lot of written requirements and a
dedicated architect that I realized how I prefer to work. I felt so productive
before and ended up in the tar pit. Where I had time before to learn on the
job _and_ be productive at the same time, suddenly there wasn’t enough hours
in the day for all the meetings, requirements reading and planning.

------
torgian
This is tough since I have changed careers three times, but i have found the
remote work I do to be highly effective for me. It’s my first software job and
I’ve been good about managing my time and delivering successfully.

I don’t get micromanaged but have clear goals that are set forth.

The only problem I’ve faced is occasionally unclear communication with other
coworkers; mostly because I’m still getting used to some of the jargon and
need to phrase my questions correctly.

Some coworkers use English as a second language too, so that can be a slight
barrier; fortunately my experience as a language teacher helps me in that
regard.

Overall I’ve been learning a lot and I can see myself working with this
company for a few years at least.

------
cableshaft
Working for a startup, working on mobile games. It was just me and an artist,
and eventually another developer in a room, just working away, while the
founder came by every 1-3 days and would look at our progress, brainstorm
ideas for the game with us, and then go off and leave us alone.

Unfortunately he had too much of a "if we build it, they will come" mentality
that infects way too many people in charge, and didn't put enough of an effort
into marketing, or making sure we were working on a project that consumers
wanted in the first place, so the games fell with a thud when they hit the
market, but I was able to focus on making and learning, and I learned a
tooooon in that period of time.

I haven't worked in a similar environment since. Big open spaces, lots of
people and distractions, lots of people constantly wanting status updates, not
much time to focus and really get work done, let alone learn anything.

Like at my current job, it's slowly gotten so bad that right now I have 3-4
hours of status updates most days (1 for devs, 1 for our department, 1 for our
business unit, 1 for our data center, 1 for a specific upgrade project we've
had for the past several months, and each lasts at least 30 minutes, usually
longer) along with other meetings so my work day doesn't really begin until
3pm most days (and there's been multiple days when I was stuck on a phone
until 10pm or later), and I'm still expected to make progress on four
different projects and manage offshore developers and get development work
done (that the offshore devs can't do) on top of all that. Things are slipping
even with me working into the evening and a bit on weekends and those meetings
are just drowning me, but I'm the only person in the department that has the
domain knowledge they need (anymore, everyone else has left or transferred to
another department) and they're stretching me beyond thin.

My own boss resigned because of this nonsense. He was the one that used to be
able to shield me from this, and his replacement has just increased the amount
of meetings I have to attend with his gung-ho, "fix all the problems this
department has ever had" now attitude.

I really need to find another job.

------
analog31
Small team

Good funding

People with multidisciplinary skill sets

Python

No silos

Access to agile contractors when a burst of effort is needed

Good reach and visibility within the organization

------
gesman
Freedom to do the work any way, anywhere.

------
systematical
Honestly working full remote. But too much of anything gets old and I'm
looking to get back into an office with 3 days in and 2 days out or even 4 in
and 1 out.

As for team dynamics it was my first job. The cheapos would hire only very
junior engineers. This meant terrible code quality but a young team eagar to
make the jump in our careers. We learned a lot from each other and many of us
are still in communication 10 years later. Despite being scattered across the
country.

------
AuthorizedCust
I am a developer and innovator. Absolute worst is being managed by sys/app
admins. They bring their cultural baggage to the relationship, screw us up by
insisting on recipe/plan-based project management, are jealous of the "fun"
stuff that developers do, and are fearful of our analytical skillset, which
we've honed differently than them because that's our focus, instead of keeping
the lights on.

Best environment is the polar opposite of that.

------
tjpnz
My previous one. Small tech team of 20 of the smartest and most driven people
I'd ever worked with, very little interference from management, lean
development processes and an exceedingly proactive IT support team. I learned
more in that place in the space of 18 months than I had in my previous 8
years. Of course this didn't last forever - we were acquired by a competitor
who burned the whole thing to the ground. We've all moved on since.

------
buro9
Managers who don't shoot you down and say no, and are supportive and
encouraging.

Innovation comes from the bottom more frequently than the top, and given time
to understand a problem and stew on what is really needed there are rare
engineers who can drive the very best work. If the environment stymies that
then all is lost, they and others will leave.

My best work has been in the context of supportive, light-touch leadership,
high autonomy teams, the ability to really own a problem.

------
alecco
I'm very productive once in a while working weekends thanks to the empty
office and being relaxed. I wish I could swap those 2 days but the team would
suffer.

------
limaoscarjuliet
Everybody needs slightly different motivation and environment. Some require
silence and closed space. Some thrive through constant interaction with
others. Some, me included, need some level of difficulty and pressure ("nobody
else solved it, this is critical, etc.").

Great discussion, but try not to reorg your workplace based on the data driven
from such small and likely biased (hn readers are not randomly selected, etc.)
sample.

------
emidln
I had an interior office with a solid door, walls covered in whiteboards,
excellent monitors, good hardware, and a fast net connection. If I needed to
ask someone something, I could send an email. If it was urgent, I could knock
on someone's door. If I wanted, I could work outside on a patio or in an
office with a giant window. There was an excellent BBQ joint on the same
block.

------
chriscaruso
I think the best is a loose structure with high level delivery times. Open
office is great for engineers in teams of 5-8 people, which is ideal imo.

Open communication is always key. It should feel like a family. The
manager/lead needs to be strong, decisive, and protect their people from all
the politics.

Learning should always be an opportunity. Engineers should feel safe taking
risks and making mistakes.

------
centerOfMass
If I may, a musical analogy:

My experience programming for myself:
[https://www.youtube.com/watch?v=-8aHsJdMEMY](https://www.youtube.com/watch?v=-8aHsJdMEMY)

My experience with agile/scrum: [https://www.youtube.com/watch?v=N9-7uLg-
DZU](https://www.youtube.com/watch?v=N9-7uLg-DZU)

------
ltr_
none. bad pay, 45 hours a week. ignorant cooksucker managers. poor
infrastructure. zoombie coworkers. I have always doing the bare minimum in my
workplaces trying to win the maximum amount of money I can, that is since I
discovered that is the way all works in my country, 0 motivation. also I'm not
a person that wants to change the world.

------
drpancake
I live in Bali and occasionally consult for companies back in London. I’m on
UTC+8 so if I start early I get most of the day uninterrupted and then an hour
or so of overlap.

It’s incredibly productive for me but I’m lucky that I enjoy programming
enough to rarely get distracted by my picturesque surroundings during the day.

------
muzani
Completely remote company, where everyone was based on Slack.

We were on throughout the day. There were no formal meetings. Just a long
stream of discussion on the future, and everyone was always synced on what to
do.

Nobody bugged or interrupted each other unless it was really important and
they had to drop everything.

------
peteretep
Last few years I've been working for a company I already knew, by myself, on a
codebase I built from scratch. Telecommuting. Customer-facing, when stuff is
done, I hand it over to their ops team. Don't think I've ever been more
productive.

------
black-tea
My best work has been done while I've been left to my own devices for days or
even weeks at a time and I've got this mad desire to build something. I can't
really control this mad desire. It happens sometimes but I can't seem to force
it. Mostly when someone else wants me to do something I can't get the desire
to actually do it. A lot of the stuff I've build has been interesting to me,
but not really useful. A few times the desire to build something has actually
produced something useful to others, though.

