
Ask HN: What is the first thing you implement at a new company? - systemtest
For job-hoppers and contractors. If you arrive at a company, what is the first thing you push for?<p>For instance, I usually implement a good feature-branch flow with branch pipelines and a strict merge-to-develop etiquette with mandatory merge requests. It makes my work easier and once the team is used to it, they also really like it. No more messy development branches.<p>I also request a small office stool next to my desk to make code reviews, three amigos and pair programming easier. It is a small thing but I noticed that people are more eager to discuss things if they have a place to sit.
======
fastbeef
For the first month or so I take a very humble listening position, even if I
immediately see things I want to fix. More often then not, there is a
background and a history to things that could lead to a) my “fix” being
unnecessary and/or ill-informed and b) friction with the rest of the team
because here comes a whippersnapper upending all our stuff.

Process and code fixes are _much_ easier once you have good rapport with the
team.

~~~
cgb223
We've got a new member on our team (from a different team within the company)
who within his first week is already trying to shake things up with "fixes"

Its driving me a little crazy. He is more senior than us, but doesn't have any
of the context of why we do things the way we do

He'll explain things to us we already know, and propose solutions to us we
tried months ago that didn't/don't work

After getting a little frustrated, I pulled him aside at the end of the
workday and sat him down to give him some context on a lot of things on our
team, but he's determined to "shake things up" and believes he's "right" so
"why should it matter"?

The one good thing about this is it's taught me just how patient and
restrained I can be, which is a lot more than I thought, but please, please
tell me that this eventually changes?

~~~
Hirak
Guys, should we tell him?

~~~
cgb223
Oh, no

What am I missing?

~~~
noir_lord
It won't get better, he's more senior, he'll probably get promoted before you
guys (and he has a head start) so he'll be your bosses boss and mandate all
this stuff.

You'll leave because surely _everywhere can 't be this dysfunctional_ only to
find that _everywhere is_ then you'll reach a grudging acceptance (people will
call you cynical) and you will live for your hobbies.

40 years from now a vein blows out and you shuffle of the mortal coil.

Alternatively it'll get better, he'll realise that his ideas while well
intentioned are upsetting the team and he'll tone it down a bit.

Flip a coin. (I wish I was joking about the binary options but well...it'll be
one of those two).

------
aplummer
I'm a consultant, the biggest thing to understand is that you don't work for
the company, you work for the individuals in the company. You need to
immediately start solving what they think is the problem, to build the capital
to solve their actual problem.

Ex. Company thinks they need more developers to ship on time (you). First,
make sure you're getting tickets done and helping them with the metrics they
know, then change the process to fix them for good once you have their trust.

If you skip to step 2, you've got someone angsty with a career on the line who
'isn't getting what they paid for'.

~~~
_wmd
Everything here, but with an important tweak to step 1: it's impossible to
know what needs fixed until you've actually gone through the motions of trying
things as they are today. It's easy to come in pushing all your 'best
practice', but any of it could be a bad idea in any particular scenario, and
it's impossible to know without context

I don't think I've introduced anything revolutionary in the last few places
I've been (going back ~2 years+), and that's also a fine outcome. Often it
turns out that causing disruption to something that works well enough is far
more counterproductive than simply leaving things as they are. Save the churn
for a big change that really provides an important benefit, otherwise it's not
worth the time

------
majewsky
One thing that I find sorely missing in many teams is onboarding
documentation. So when you come in, document everything that you need to do
(required permissions, development environment setup, mailinglists,
subscriptions) and how to do it.

~~~
cwingrav
Every new person on my teams, I have document what knowledge they are missing
and what their questions are. We then fix and update the documents we have to
address this. If you're on a growing team, this approach saves time/money in
the long run.

------
ben0x539
Well, first I gotta rebuild the release process on top of nixpkgs, then, after
rewriting the core product in rustlang, I can focus on replacing all the
developers' macbooks with linux machines.

~~~
maxxxxx
I already want to hire you!

------
Matheo05
I am a bit surprised all the comments so far are tech or process oriented. On
my side, I try to say "Good morning" to everyone and get to know them a bit
better. It allows me to quickly identify the key resource I need to get answer
and being friendly usually make them reply faster.

------
triggercut
1.Find an established religiously held standard that has little actual value
(tabs vs. spaces).

2.Spend the first month gas-lighting everyone into changing to the oposite
until enough people force a change in policy.

3.Survey my new kingdom with my loyal band of disciples (whilst intermittently
switching between tabs and spaces to enrage the holdouts)

4.Quit

------
astonex
If you just arrived at a company why are you pushing to change anything. They
obviously already have a working process and you should be careful to change
anything that works, especially when you may not yet know all of the more
hidden details.

~~~
PeterisP
It depends on why you're brought in to the company. Especially in management
it's not uncommon to hire people with the explicit notion that they _don 't_
have a satisfactory working process, it needs significant changes to achieve
the desired results, and the new hire would be expected to start fixing the
current process almost immediately.

~~~
lijason
I would argue that even then you need to assess before making changes. If
you're brought on for your expertise in process, you need to trust your own
judgment on where the problems lie. Whoever is hiring you may have a sense
that something is wrong, and may even have areas they think are broken, but if
you're brought in as the expert, you should assess for yourself.

------
ryandrake
I once joined a company and found out on day 1 that they had:

1\. No source control system

2\. No bug/issue tracker (or formal software QA)

3\. No build automation

4\. No dedicated build system

5\. No pre-launch checklists

Basically, the latest release was whatever happened to be on one of the
engineer's hard drives whenever someone frantically ran in and said "we needed
to release!" You can imagine how fun it was to repro when customers reported
bugs. And they did, Gandalf, they DID...

Those were the first things to address because they were obvious gaping wounds
and I could implement them myself without really having to convince anyone.
The CEO thought they were a waste of my time (I hired you to write codes) but
didn't actually stop me from setting them up. The next things lacking would
take more effort to fix because they were people/process dependent: like no
code reviews, no software development process, no bug triage process, etc.

~~~
JBReefer
How long did you last? I worked somewhere like that, most engineers lasted 3
months, I managed to squeeze out 4!

Places with issues like that tend to have TONS of other very serious issues.

~~~
ryandrake
You guessed right. Turnover was a huge problem too. I lasted just over a year,
and only because it was during the depth of dot.com recession 2.0 and there
weren’t exactly jobs available on every street corner.

The technical problems were merely symptoms of structural and leadership
problems.

------
spiritcat
First day I find the best dev and kick his ass. Gotta set the tone.

~~~
thecupisblue
Pee on their desk. Establish territorial dominance.

~~~
skocznymroczny
Make sure to get a MX Blue mechanical keyboard, so that everyone is aware of
who's doing most of the keyboard mashing around the office.

~~~
zrobotics
Cherry switches? Millennial... You really need an old IBM, plus it doubles as
a weapon if your dominance displays backfire.

~~~
beat
My first pro gig was on an RS600 workstation. I miss that keyboard.

------
calciphus
I'm a product manager, so I'll vary a bit from the development-specific things
already listed. Basically, when I get a new product line (or company), it goes
the same way:

1\. Gather hate mail. Find whatever complaints you can about the product and
team you've just inherited.

2\. Use the product. Try and break it. Act like an angry QA engineer.

3\. Find the person or people who support customers on the product. Ask them
what makes their job suck. Ask what's broken.

4\. Ask them why they think it sucks / is broken - preferably outside the
office (coffee, lunch, etc).

5\. Meet dev team. Ask them why the product matters. Gauge their interest and
understanding of the problem and customers. Ask what they think is important
to address as a team.

6\. Combine answers to 3-5, identify common threads. Look for places where
there are common blocking factors (cost, time, focus, politics, history).

7\. Find something to work on with the team, that can be delivered fast. Talk
about what you want to do with support folks (from q3). Sanity check, make
sure dev team understands the value of what they are working on.

8\. Check in with superiors. Make sure you understand what's important to
them. Talk about what you've heard.

I've found I can't come in and expect to be an expert in a given area
overnight. But I can be good at asking questions and spotting painful things.

(edit: formatting)

------
monk_e_boy
Hahaha! Good lord. First I push for a DEBUGGER. Second I demand they test
their backups. An untested backup is just a delightful wish.

After months of push back for those two and I've made myself a hateful person
to all involved I ask for ALL code to go into repos. Often there is a bunch of
"Oh, my code doesn't need to go in, for reasons." No FUCKING NO, your code
needs to go into a repo and needs reviewing.

The boss needs all passwords. Okay, not your personal passwords, but if you're
not in and you're sys-admin, we need to get into the f-ing box. You can not be
the only person with a login. Create more users, give those users permissions.
So many companies have one guy/gall who has access to some critical part of
the puzzle and no one else knows how to even log into it, let alone all the
hacky scripts that are needed to push a change live.

Automatic testing. We almost got there in one company. So close... until one
day they ran out of money. We found that an SQL statement wasn't coded right
and we hadn't billed 50% of our customers. Ever. No a dime. Not a cent.
Accounts never realised. Even in the early days when they only had ten or so
customers. The billing record shows they only sent four bills out. Come on
people.

~~~
yjftsjthsd-h
I find it helpful to have a "misc" repo just for those weird not-quite-one-off
scripts and the like that don't really fit into the main repos.

------
pards
>> For the first month or so I take a very humble listening position

.. and then

    
    
      - Everything in source control
      - CI
      - Static code analysis
      - Artifact repository
      - Automated deployments, incl database and configs
      - Branching strategy & pull requests
      - Standalone dev env per developer

~~~
chatmasta
What do you use for an artifact repository? I’m assuming you mean the cached
artifacts of builds, but also vendor artifacts/cache like npm_modules or
docker containers?

This sort of vendor dependency management is a problem I haven’t found a great
solution for yet. I’m actually thinking about creating a product that’s
implemented as a proxy and supports multiple package managers, including
docker, and caches all downloads keyed by branch. This way in the event of
some catastrophic dependency failure you have a place to find the last working
set of vendor dependencies that didn’t break the build.

Would anyone be interested in this? What is current best practice for this
workflow?

~~~
jzl
One popular option:
[https://jfrog.com/artifactory/](https://jfrog.com/artifactory/)

------
thecolorblue
This is not technical, but I always push for monthly performance reviews, with
clear goals, and a weekly dedicated time to check in with a manager once a
month to make sure I am spending my time on the right things. It doesn't
always happen, but my experience has been the harder it is to get these things
the less likely I will feel productive.

------
lvh
Latacora perspective, AWS specifically: go install aws-vault.
[https://github.com/99designs/aws-vault](https://github.com/99designs/aws-
vault)

There are a ton of benefits to aws-vault. Strategically: getting everyone on
an aws-vault workflow is step one to eventually making your IAM story great.
We'll be publishing some general stuff about how we think you should start
cleaning up your IAM story. We have Strong Opinions(TM) on how to get you from
"bunch of people have * : * perms with keys they have on disk" to best-in-
class, BeyondCorp-compliant temporary perms acquired on trustworthy endpoints.

(FWIW: also undersigned re: start by listening. Latacora starts with an audit
too, but that feels like a cop-out answer :))

~~~
falcolas
Oops. I was thinking of the wrong tool. Personally, my biggest peeve with
temporary IAM credentials is the duration. Having them invalidate in the
middle of a Packer build is a real mood killer. Our own company got them
extended to 12 hours recently, which was a huge win in this department.

Original content - about Secrets Manager:

AWS Secrets Manager is stupidly expensive for a password manager that rotates
passwords. It can't even rotate all passwords, just those for a specific
subset of AWS services.

Should instead start with parameter store (which is free but still offers
encrypted password storage) and then figure out what parts really need a
rotating password _and_ that are operating with services which Vault can
rotate passwords for - at which point you migrate only those.

~~~
lvh
You appear to be confusing aws-vault, a gratis and open source project that
manages IAM credentials, with AWS Secrets Manager, a hosted AWS service that
stores and manages secrets.

I agree AWS Secrets Manager is overpriced but I doubt it's a major expenditure
for anyone. You should probably just use KMS instead and dump the ciphertexts
wherever you want. Parameter Store is a fine place for them.

~~~
falcolas
I did. Clearing up.

That said, it is a major expenditure when used as part of the automatic
workflow. And parameter store has KMS encryption/decryption built-in.
Alongside full IAM level isolation.

~~~
lvh
So, concretely: $0.40/secret/month (prorated if < 1m) + $0.05 per 10,000 API
calls. KMS: $1/CMK/mo + $0.03 per 10,000 requests.

What are you doing with it that makes it a major expenditure? That seems like
a drop in the bucket compared to anyone's compute. Are you dumping 500 secrets
in it?

~~~
falcolas
We were looking at it for a configuration management backend. So, yes, 500+
values, consumed by microservices.

I still say - the only real value even when compared to other AWS services is
the rotation, which currently only really works with DBs (and then only if
your service connects to the Secrets Manager directly, with every DB open).

~~~
dantiberian
Just a note on Secrets Manager which you probably know, but is worth
mentioning just in case:

Secrets Manager charges per Secret, but if you are storing non AWS values (API
keys), then you can put several secret values in one Secret. Not sure if your
500 values number was 500 Secrets, or 500 secret values which could perhaps be
grouped logically together into a smaller number?

------
maerF0x0
I often walk through the Joel Test with sharply declining urgency ...

That is I more or less demand source control, work on automated builds/tests
(on each commit, not daily), start to log everything I see in JIRA (or another
tracker), Look for an up to date schedule (ie, discern business priorities and
timelines), attempt to start specifying how future things ought to work, train
my coworkers to see when I'm wearing earplugs to drown out their non work
related chatter....

[https://www.joelonsoftware.com/2000/08/09/the-joel-
test-12-s...](https://www.joelonsoftware.com/2000/08/09/the-joel-
test-12-steps-to-better-code/)

------
gwbas1c
I try to understand what the real problems are, and if there is the will to
fix them. Then I try to understand the real social hierarchy and everyone's
biases.

In the last two jobs I've started, both had serious problems from using an ORM
framework and dependency injection framework incorrectly. In one company, the
project ended up going nowhere because of incorrect biases towards using a
database. In the other company, everyone knew that if they didn't fix the
problem, they'd go out of business.

I left the company that didn't want to fix its code, and still work at the
company that fixed its ORM and dependency injection problems.

[Edit] The project that went nowhere failed because the lead programmers
didn't know how to use a database. They wrapped it with layers of frameworks
and code generators. The layers took so much time to work with that the
schedule dragged out, and we missed our market opportunity. There was no will
to fix the real problems, so ultimately I knew I had no future at the company.

------
troels
The first thing I do is work to gain enough political leverage so that I can
manage my own time.

~~~
yitchelle
Sounds like a nasty place to be in if the first time you do is politically
based.

~~~
troels
I realise the way I put it may sound ominous, but it's for the good of
everyone involved really.

Most organisations are shockingly ineffective. Micromanagement and lack of
long term planning is abundant. I get hired because I'm good at writing
software. This is not wrong, but I can add much more value if I deliver what
is needed rather than what is asked. My goal is simply to be able to do that.

~~~
gtt
Could you share a longer description of how do you do it?

~~~
troels
I'm afraid I'm not deliberate enough to have an actual playbook I go by. It's
more like; this is my goal for the first month or two.

------
bloopernova
One of the first things I do, as a sysadmin/devops person, is to look at how
"easy" it is to communicate.

In other words, does this department have group chat, how easy is it to add
documentation, how do I tell who is on call, am I being told things face to
face or am I being walked through existing documentation?

This is related to a lot of deep issues in operations or development, I feel.
If the only documentation is fire and forget word documents in a windows
shared drive, does anyone read them? Can I search for the information I need?

Is the department ruled by one or two people who hold all the knowledge? Are
all decisions made by those people, or are there people who never read emails
and always demand face to face meetings to discuss issues?

Communication is key. What you do and how you do it follows on from how, what,
why information is shared.

~~~
xaedes
How do you improve communication issues when you discover them?

For example suppose you encounter documentation by word documents in windows
shared drive and an set up but not really used confluence (so we don't need to
think in this example about setting up a system technically, but how to make
people use it).

------
maxxxxx
I think the first thing you should implement is your own understanding of the
current codebase and processes. I have seen it now several times that new guys
come in and immediately push for their pet architecture without even trying to
consider that we are not complete dummies and a lot of things are there for a
reason or are at least not that easy to change. Usually it ends with them
being rejected and then getting frustrated because they didn't get their way.

On the other hand we also have people come in, help with the current codebase
and after a while they make proposals for improvement that are based in
reality. These people integrate well and are quickly respected team members.

------
gpetukhov
Linting and code style guidelines. Easy to introduce, but makes a big positive
difference.

~~~
colinbartlett
In that vein, I invariably have one massive commit on every project to remove
trailing whitespace first. That way when my well-behaved editor removes them
with each commit, it's not littering up the diff.

~~~
systemtest
My opinion is that every team member should have the same editor with the same
settings. The settings should be easily accessible from Confluence or a
similar knowledge base.

~~~
PurplePanda
what's the point of that?

it takes a while to learn how to use your text editor well, and everyone is
probably good at a different one. but they all pretty well have the ability to
produce the same result, so why bother forcing one?

it's better to (have a tool that can) specify what the end result should look
like and let people work the way that they are good at.

~~~
systemtest
In my team everyone uses IntelliJ Ultimate with the same settings.xml file. We
all have the same automatic tasks that happen on each commit: reformat code,
optimize imports, check TODOs, perform SonarLint analysis. This has greatly
reduced frustrated merge-requests filled with unimportant details such as code
formatting and newlines. It has also greatly improved the code quality because
it will warn you that you left a TODO in the code or that a certain method
could also be private before you commit the code into the repo.

Nobody has a problem with this, although in the Java world every corporate
developer uses IntelliJ anyway. A couple of legacy project teams are still on
Eclipse.

------
lgleason
It depends on the project. The biggest thing is to assess where the team is
at. I just left a project where the team had serious issues and the leadership
did not have the desire to fix it...IE: a tech lead that was more of a mid
level dev running a command and control style thing. The team, with more
experience, did not have a say in the architecture, what they got to work on
etc.. All devs had to get their commits past the mid-level lead, the lead
would reserve most of the fun and hard stuff for themselves and leave the
scraps for the rest of the team. The lead had multiple silo'ed efforts and, as
a result, had a higher number of commits etc. on code base partially because
they were constantly declining PR's from the rest of the team to do it their
way.

Now if you have a team that is actually open to your ideas things are VERY
different. I've worked on them and they are amazing. The key thing is to
evaluate where they are at and apply what is going to work for them. The
biggest thing is to avoid the one size fits all approach.

With the original comment for this thread, my biggest issue out that gate with
their approach is that you are using a lot of branches which negates the
benefits of CI etc.. Why not instead try to figure out how to reduce branches
and have more people checking in working code to dev with unit tests?

------
cozuya
(front end js)

My new favorite tool is the ridiculously named husky package, which allows for
configurable git hooks inside of package.json. Specifically what I'm doing now
is precommit eslint and prettier, and prepush test:all i.e. people on my team
will be unable to commit if they fail lint and unable to push if they fail
unit tests. There's of course positives and negatives to this approach but the
former significantly outweigh the later in my experience.

~~~
zrobotics
And you do this in a new job? Introducing a linter the first week seems like a
great way to make your new coworkers hate you. Sure, it's a good thing to do,
but if your teammates aren't already using one then unilaterally introducing
this into the commit process seems a little radical.

~~~
cozuya
My OP should have called out that I specifically let everyone know that I have
no problem with them using git commit -n and git push --no-verify to get
around it if they are in feature branches. But yes I implemented this on day..
2 of my current position which was lead of a greenfield project.

------
beat
I job-hop a lot in corporate environments (mostly Fortune 100), doing DevOps
for legacy systems/teams rather than coding. As such, I don't push for
_anything_ when I first arrive.

It can take a while to understand how all the moving parts interact, both
technically and organizationally. The systems in question are sometimes
responsible for tens or even hundreds of millions of dollars in business, and
critical corporate functions. Wading in with "Hey, I know more than you, stop
doing that and do this instead" is the short path to sudden emergency downtime
for production systems! And that's _knowing_ they hired me _because_ I'm the
expert and know more than them.

So there will be processes that are really, really stupid. Slow, inefficient,
maybe completely dysfunctional. But if they work, they work. Fixing/replacing
them means interactions with other processes that can be very difficult to
pull off. Process is usually a Big Ball of Mud Antipattern at the point I'm
brought in, and fixing anything in the Big Ball of Mud is a challenge.

As for legacy apps... yes, built with antiquated technology, often poorly
implemented, with a lot of uncertainty and fear. Change is really scary. What
to do about this stuff depends on what the long-term vision for the product
is. Is it in maintenance mode, or under active development? Is there a plan to
replace it? Is there a _realistic_ plan to replace it that has working results
and a viable schedule? Generally, the best thing to do is leave the scary ugly
thing alone. It was probably done pretty well back in its day.

Where I usually find myself making progress early on is finding things that
are broken due to communication problems. One team says one thing, the other
team says another, and everyone is mad and nothing gets done. Often, it's just
a matter of rephrasing things to both teams, to find common ground and a way
forward that everyone wants.

So really, my expertise isn't cool tech. It's being a good communicator on the
engineering rather than the management side, someone with both development and
operations experience who can speak to the concerns of both sides, and has
seen similar problems in other organizations (big organizations like these
usually have 10+ year people in key positions, who have no idea how the rest
of the industry works anymore).

So yeah, the first thing I push for? Learning the lay of the land, so I can
start charting paths.

------
jdwyah
FeatureFlags for sure. They don’t force anyone to change their day to day but
allow them to adopt better practices at their own speed.

------
acconrad
The very first thing I do is update documentation.

You're a fresh set of eyes and so documentation for onboarding, setup, and
building the application on your laptop is the kind of thing that often goes
by the waist side.

Did a step not work because you've updated your OS? Was there a critical typo
in the terminal? These things provide immediate value to all future hires.

~~~
delinka
...by the wayside _

------
jtreminio
A Docker or Vagrant setup to match their prod as closely as possible, for
local dev purposes.

It boggles my mind how many developers _still_ install PHP/MySQL/Ruby/Node/etc
on their daily desktop and are surprised when something doesn't work as
expected on production.

~~~
yeswecatan
Do you typically choose one over the other?

~~~
digitalsushi
I'm not them, but for me I would use Docker if I am tearing the stack up more
than a dozen times a day, and Vagrant if I am doing it less.

I doubt I use either of them correctly. But I do love the way I use them.

~~~
creatornator
Same. I generally try Docker first. With multi-stage builds, you can reduce
container build times by a lot (after your first build), as opposed to
reprovisioning an entire vm every time you need to nuke your dev environment
and start from a fresh image.

------
LoSboccacc
It war rare to find places with automated build. My first priority was always
to get humans out of the equation because as a contractor you need to trust
the pipeline and you need to be sure whether your code hit production or not
since it’s critical in issue management.

------
noir_lord
Proper (as in working and recoverable..tested to be recoverable under the
worst case I could think off) backups.

I wish I was kidding but the last 'complete' back up they had was from
mid-2014 (and the system was still in initial development from 2013 late
2016), I started June 2017.

Outsourced development company (and bad developers and..well stuff I'd never
seen before, RAID on the server but only 1 disk in use, 64bit Xeon's running
32bit Debian...and on and on it went - A backup server that had nothing on
it..I mean literally nothing, the entire system runs as root (because the way
to solve your inability to understanding the linux permission model is just to
run _everything as root_ __apparently __).

------
tboyd47
The first thing I do is fix bugs. It lets me know the types of problems that
come up.

------
elliotpage
Abolish overbearing dress code, if one exists. Social/lunch outing on Fridays.

------
sysbell
Internal URL shortener, every single time. They get rave reviews and in one
case ended up being considered a core service that _had_ to be up.

~~~
jamestimmins
Can you explain what the purpose/benefit of this is?

~~~
insomniacity
It turns a mess of internal sharepoint/wiki/confluence links into an easily
memorable namespace that can be 'linked to' verbally or on post-it notes.

A common hostname is 'go', so when you launch some new programme, project or
tool, you can put 'go/projectname', or 'go/toolname' in places like chat
topics, email footers and presentation slides.

Applicable in larger places that end up with a mess of different documentation
systems, and where trying to unify everything would be a waste of time.

------
nojvek
Spend time talking to people, learning what the hard and hairy problems are.
Playing with product and getting a feel for what customers experience.
Dabbling in code, trying to make a mental architectural map and asking
coworkers to validate assumptions. “What happens when someone does X?”
questions.

First week is lots and lots of asking noob questions and documenting them if
it’s not already done.

------
mkbkn
Mandatory learning something related to the work. Either the company schedule
professional classes for that or reimburse the equivalent amount of money if
you self-learn.

Assuming your employees to know everything and not let then learn is a path to
your organization's downfall.

Ben Horowitz makes a good case about it in his book _The Hard Things About
Hard Things_

------
phoenix24
CI/CD. Revision Control. Artifactory. VPN.

~~~
dboreham
VPN?? For what?

~~~
ThePadawan
Not parent, but generally to be able to do remote work.

Production goes down and you're not at the office (1h travel)? Now even a 1min
fix will cause 1h + 1min of downtime.

~~~
heavenlyblue
So is your cloud in the office then?

~~~
EamonnMR
The cloud can also be on a VPN.

------
BerislavLopac
Update the codebase to Python 3.6.

~~~
dswalter
F-strings alone make the upgrade worth it.

------
vortico
What's three amigos? Never heard that term in programming.

~~~
clemParis
I had to google that as well. It seems to be an agile practice [0] that
consist in gathering a developer, a product owner and a QA tester in order to
produce acceptance tests using the format given/when/then.

[0] [http://jonkruger.com/blog/2012/01/04/the-three-
amigos/](http://jonkruger.com/blog/2012/01/04/the-three-amigos/)

~~~
BerislavLopac
Nice. I suppose the code is the singing bush then. And the end user is the
invisible swordsman [1].

[1]
[https://www.youtube.com/watch?v=e9vPvHO8Kp4](https://www.youtube.com/watch?v=e9vPvHO8Kp4)

------
soulnothing
Documentation is my biggest thing. I start with onboarding, CI/CD. Then start
adding api and archicture documentation. This forces me to learn, and ensure I
digest well enough to explain to other people.

Once that's done I start adding unit tests, monitoring, and additional
dashboards.

~~~
dood
Documentation has some great properties as something to work on in early days
(so long as you aren't immediately firefighting).

* Documentation always sucks, no-one wants to do it, and everyone knows it has room for improvement. It shows you're willing to roll your sleeves up and do the less glamorous stuff.

* Working on it prompts you to ask simple questions so is a good way to get to know people on the team, and in the process learn the history of the team, why things are the way they are, and where the dark corners are.

* You're immediately creating value, rather than doing bugfixes no-one cares about or having meetings about things which are months away from fruition, and demonstrates you're here to make things better for everyone.

------
chandmk
Joining a new company is like starting a new life, which doesn't seem to
happen many times in a life time. It is like you are being given another
opportunity to start fresh. First thing then to do is gain respect, learn the
culture. It is going to be uncomfortable for a while, so it is important to
keep the opinions under check. Let the actions speak more than words. Remember
that every design issue is a choice made by someone else to the best of their
abilities. Finding a way to move forward without making too much splash
automatically unlocks the doors. There will be lot of things to implement and
you will find a way and while doing so you will learn a lot.

------
lvh
Latacora, corpsec perspective: audit Google Groups and OAuth'd apps, run a
phishing red-team exercise.

Finding appsec bugs matters but maybe not so much if everyone just signs over
whatever privilege apps ask for and it'll exfil whatever's on Drive.

------
KaiserPro
Single Sign on.

There is nothing worse than loads of different accounts that are all for the
same person.

~~~
yjftsjthsd-h
Bonus points if the multitude of accounts don't map 1-1 to people. Sometimes
an account is for a user, sometimes it's for a team, sometimes it _was_ a user
until they quit and it became a team account but still with the original
employee's name. The accounts are all individually managed, of course, so
getting access to something requires raising a ticket to the relevant team,
then testing whether the account they gave you actually has permissions to do
your job. But sometimes you find that they only gave you read-only access
because only _they_ can actually modify that cluster. Oh, and sometimes you
find that an ex-employee only had maybe half of their accounts deactivated,
and one of them has been recently used, and you have to find out whether
you're looking at a security breach or just "recycled" account use.

We use SSO now. It's nice.

------
garfieldnate
I start creating a glossary of all of the unique and important terms and
concepts used by my team. This is a great way to confirm understanding and
becomes great documentation for the next person to join.

------
wozmirek
Wiki - confluence has a nice flat cloud offer for $10/mo for up to 10 users.
Not only for tech people, but also for non-techs: marketing, sales, office
people. And you can connect it to jira.

------
kennydude
Document things to get an idea what's going on. Add comments and probably
tests (but don't rewrite) to the 2 page function to see if you understand the
style of the previous developers.

------
tynecomputers
$3500+ for business travel UK/USA vs $800 for economy. I always get companies
to offer the employee half the difference to fly cheap. Win Win!

------
CodeWriter23
I’m a consultant. Honestly, I identity a good source of decent coffee, even if
it means packing some at home. A reasonably comfortable chair. And if the temp
is out of my comfort zone, I’ll pick up a desk fan.

Making sure my creature comforts are in place helps ensure my productivity.
Also, on my way out I ask the most helpful person if they’d like the fan and
leave it with them. A calling card of sorts.

------
viggity
I am usually new to the business domain, ergo, I start compiling a "Dummy's
Guide to [Plant Genetics]" or whatnot. The code and the tools used to work on
the problem domain are always changing, but the basics of the business usually
are not. My guides help new hires understand why the business does what it
does so they can start adding value more quickly.

------
linsomniac
I mostly do ops rather than dev, but:

First, is anything broken? Any RAID arrays that are degraded or failed (yes,
I've come into shops where that was the case). That sort of thing.

Are systems secure? Are updates applied? What sort of network security is
there? If there are known holes, has anyone compromised the system?

Monitoring, how do we know something is having problems before the phone
starts ringing?

------
walshemj
as a job hopper and " contractor" unless you have been explicitly brought in
to set up better processes id STFU.

------
golergka
Lead developer here, commonly brought in to overtake projects. Proper workflow
for the team is the most important thing: make sure that each team member has
an easy and unintrusive algorithm or picking small tasks, completing them and
relaying them to the next one responsible makes team morale and planning a lot
easier.

------
goldhand
A eslint-config for the team!

I get that setup with a style guide during the down time of the allotted
"onboarding" phase.

------
colinbartlett
CodeClimate is a big one for me. Having some static analysis to track the
team's progress over time is huge. It's nice to have a neutral third party
robot doing the complaining about poor code.

Fortunately, CI/CD seems to be pretty prevalent these days. But if it's not in
place, that's always first.

------
viach
Implement or fix basic integration testing infrastructure. It is usually
broken or doesn't exist.

------
lloeki
I usually take a humble attitude as I pace myself into things and blend with
the team, but the first thing I try to take care of is make sure the Joel Test
is passed. It's amazing so many shops and companies seem content with a score
of 2 or 3.

------
motoawk
I always test the backup restore process. It's amazing how many times you find
issues.

------
Adamantcheese
Delete as many things as possible without breaking anything. Lots of crap
tends to build up and nobody wants to keep lugging around several hundred
megabytes of useless auto generated build garbage.

------
blattimwind
CI. Code analysis. Revision control. Something for documentation.

------
tibbon
I work on Ruby 95% of the time. If there's no well-configured Rubocop setup, I
get that into place as my first order of business almost immediately.

------
twic
> a good feature-branch flow

Ain't no such animal.

[https://trunkbaseddevelopment.com/](https://trunkbaseddevelopment.com/)

~~~
UK-Al05
Trunk based development is a feature branch flow.

What do you think your local copy logically is?

------
codingdave
The first thing I want to see is a culture where people listen to others and
understand where everyone is coming from before pushing their own agendas.

------
JeanMo
static code analysis e.g. Sonarqube.

CI/CD

------
Jayvino
I connect to the mainframe and then execute variables on the system. This
gives me access to data I would otherwise not have.

~~~
cncrnd
Mainframe? Sounds like back in the 80s or 90s :)

~~~
dboreham
Like the post about overbearing dress code. Perhaps some irony. Or time-
traveling posts..

------
anotheryou
if there are smokers, join their breaks. it's a good way to learn about
culture, history and customs of a team.

------
emodendroket
I request good ergonomic equipment so I don't needlessly work in pain.
Otherwise I'm pretty flexible.

------
metakermit
Lately I've been adding prettier.io to all the new projects I join. Great
helping tool :)

------
jacquesm
Proper logging, if they don't have it. Otherwise, take a hard bug and fix it.

~~~
adyavanapalli
Do you know any resources for learning this?

~~~
jacquesm
Any open source project with open bugs (that's most of them).

Proper logging: that's a complex subject and it took me a good chunk of my
career to figure that out.

------
onion2k
Company funded Friday lunch.

~~~
readhn
with opportunity for employees to pick their own lunches.

------
nelsonic
#tl;dr

Regardless of how long you stay with a company/team always leave it better
than you found it. Requirements Gathering, Paper Prototype, MVP, UX-testing,
Docs, Tests, Linting, Static Analysis, Git/GitHub Workflow, Team/Personal
Learning, Code Quality, CI/CD, Pipelines.

#longform

Assuming the company is new to _me_ but has already been writing/shipping code
for before I arrive ...

I ask clarifying questions to get "up-to-speed":

1\. _What is the Problem?_ \- Understand what problem they are trying to
solve, do users actually realise they have the problem or is it a case of
"build it and they will come"...? (it's _vital_ to know why we are building
something to avoid wasting lots of time on something people don't want! see:
Bill Gross "Why Startups Succeed":
[https://www.ted.com/talks/bill_gross_the_single_biggest_reas...](https://www.ted.com/talks/bill_gross_the_single_biggest_reason_why_startups_succeed)
or Paul Graham "Make something people want":
[http://www.paulgraham.com/good.html](http://www.paulgraham.com/good.html) A
"red flag" is when there are no clear "personas" for prospective users. see:
[https://www.interaction-
design.org/literature/article/person...](https://www.interaction-
design.org/literature/article/personas-why-and-how-you-should-use-them)

2\. _Workflow?_ \- Is there an existing _clear_ " _workflow_ " for collecting
requirements, defining user stories and getting the features built and UX-
tested? or is it all verbal between "founders" and the one dev? (comes back to
how old/new the company is; is it a _brand new_ "startup"...?)

3\. _MVP Defined?_ \- What " _MVP_ " has _already_ been _shipped_? who built
it? what tech was used? was the work "outsourced" e.g: to remote contractors
or an "agency"? was a revision control system used e.g: GitHub? If no MVP has
been shipped, is it at least clearly defined in the backlog?

3.a _Paper Prototype?_ : what is the _minimum_ you can do to test an idea?
See: "Google Ventures Design Sprint":
[http://www.gv.com/sprint](http://www.gv.com/sprint) &
[https://youtu.be/Z8MOwcqZuuU](https://youtu.be/Z8MOwcqZuuU)

4\. _Technology & Tool Selection_ \- If the personas & problem is well
defined, and minimum features captured in a "backlog", then we can discuss
technology choices. It's _essential_ to have these choices documented
_somewhere_ , because this question will come up in the future and "because
it's popular" on [https://stackshare.io](https://stackshare.io) is not a good
_reason_ for selecting a tech/tool; whereas "it was the best choice for our
specific problem/domain" is a good reason to choose a tech/tool e.g:
[https://github.com/dwyl/technology-stack](https://github.com/dwyl/technology-
stack) For example: if you're building a robust real-time messaging system,
use Elixir/Erlang every time. If it's just a "low budget quick-to-market" MVP
to get a demo out to start testing and get "funding", use Meteor:
[https://www.meteor.com](https://www.meteor.com) (and accept the "technical
debt"!)

5\. _Developer Workflow_

\- _Documentation Driven Development_ : If it's not already being done, focus
on this _first_ , without clear docs for the work done, "you're going to have
a bad time" when trying to understand (never mind "fix") things in production.

\- _Test Driven Development_ : If tests aren't already being written,
understand why and fix it. Should you follow ("strict") "Test _First_
Development"? Or is it "OK" to write tests _after_ the code? The answer is
simple: if you want to write _less_ code that is more reliable, learn how to
(and discipline yourself/team) to write the tests first! see:
[https://github.com/dwyl/learn-tdd](https://github.com/dwyl/learn-tdd) If
you're stuck writing the tests for a feature/idea ask for help till it becomes
natural!

\- _Pre-commit Hooks_ : Make the tests, "linting" and doc checks run on the
developers localhost before they can commit. See:
[https://github.com/dwyl/learn-pre-commit](https://github.com/dwyl/learn-pre-
commit) If your tests "take too long to run" don't use it as an _excuse_ to
disable the pre-commit, fix it! Having slow tests (and build process in
general) is a cancer that will gradually "sap" the productivity & energy of
the team! Analogy: it's _much_ more difficult to get physically fit if you are
an obese "couch-potato" than if you simply _maintain_ your fitness each day;
"Unfit" Apps die young.

\- _Code Analysis_ : If there is an automated tool for your chosen
tech/tool/stack use it! Even if costs money, think of it as "member of the
team" not an "expense". It will _always_ save you time in the long run.

\- _Continuous Integration_ : Pick a CI system based on your tech/tools and
implement it for your app. it only takes a few minutes:
[https://github.com/dwyl/learn-travis](https://github.com/dwyl/learn-travis)

\- _Code Review_ : Use GitHub Pull Requests (or the equivalent on BitBucket,
GitLab, etc.) and leave helpful comments, besides pair-programming this is one
of the best ways to learn as a team.

\- _Continuous Delivery_ : When Pull Requests are merged, they should be
automatically deployed! If the app/product/company is _new_ , use Heroku for
deploying your app! Don't waste time on DevOps till you need to! Migrating to
AWS or GCP is _easy_ once you have "traction" (i.e. if you're paying Heroku
$200/month, you can _justify_ orchestrating/managing you own DevOps/Infra).
see: [https://github.com/dwyl/learn-heroku](https://github.com/dwyl/learn-
heroku)

\- _Continuous User Testing_ : Ensure there is a clear process for testing the
new features you are releasing. Ideally "get out of the building" and test
with "real users" _in person_. see:
[https://steveblank.com/2010/03/11/teaching-
entrepreneurship-...](https://steveblank.com/2010/03/11/teaching-
entrepreneurship-%E2%80%93-by-getting-out-of-the-building) "weekly" should be
the minimum user-testing cycle. No "excuses" to not test! Use online services
like [https://www.usertesting.com](https://www.usertesting.com) if you aren't
physically near to your users.

\- _Continuous & Validated Learning_: Instil the habit/culture/expectation
that _everyone_ should keep learning. If people "stagnate" everyone suffers.
The Product will be worse, the best people will get jaded and leave. Learning
is _easy_ to forget but it's just as easy to maintain, it's just a question of
routine.

~~~
Geee
Thanks, I'm going to implement these in my company.

------
apfel912
CI/CD

Dockerize all the things

~~~
leksak
Where do you stop short? I'm conflicted. I sometimes look at Docker and am
like "this is great", but I also sometimes look at a plethora of Dockerfiles
and I'm like... what are we doing wrong? Do you, for instance, Dockerize small
Python tools (or similar)? How well does this work?

I remember one project where we had tons of small Pipenv projects and one pain
was that a few were Python 3.5 and a few others were Python 3.6. I guess
Dockerizing these would have mitigated the pain but honestly I am a complete
Docker n00b and wouldn't know how to go about setting this up in a way that
wouldn't cause more pain and another layer of abstraction.

Any tips? Reference material, etc?

~~~
yorwba
> we had tons of small Pipenv projects and one pain was that a few were Python
> 3.5 and a few others were Python 3.6

Isn't pipenv supposed to take care of that? You _pipenv run_ the tool and it's
automatically executed in the right virtual environment.

~~~
leksak
You can't set it up without the Python binary you want already being on the
machine which may be a hassle if you are chasing "latest" and you have
machines in your ecosystem that run old stuff, for instance, Jenkins nodes.

------
lowlevel
Fraud prevention, gate keepers.

------
Annatar
The first thing I implement at a new company is configuration management using
OS packaging.

------
stuntkite
Auth. If you can stomach it, back it up with a real directory service.
JumpCloud is a great way to do it. It's free up to 10 users. You can use it
with Google Hosted Apps as your user backend. You can set it up in 10 minutes.
It has TONS of features, you probably won't look at them all once you can use
it as an SSO/LDAP provider, you can forget about all that until you need more.
Also you can easily replace it with something self hosted if you grow to the
point of needing to do something else.

Determine if you need organization level RBAC (Role Based Access Control).
Does your app need to have account managers at the customer level? You
probably know from the outset if you'll face this problem. It's a big pain if
you get someone to implement your product somewhere, then they lose that
person and they have trouble accessing their account. Not that you can't
provide support to solve it, but the legal side can get tricky and no matter
what you lose face with the customer over the frustration. DockerHub messed
this up IMO and that's why they haven't added it, because it's too complicated
to add now.

You can easily have a simple SSO layer on top of it so your super admins come
from the LDAP(or other) and user/customers are a separate DB in your existing
app. It can be really expensive to add complex auth or change how it works
later, but a stitch in time makes it easy to grow and adapt. This helps
tremendously for DevOps, deployment security, managing things like white label
licenses, and a host of other things.

Once you have it, it keeps you from writing terrible solutions to dance around
having things like user account profiles. API keys if you need to offer them
become easier and control of important assets are much less scary. Also you
are ready to implement things like IAM management or whatever to keep track of
deployment keys before you end up with a giant pile of security holes.
JumpCloud offers a pretty turnkey IAM integration for AWS and others.

After that, getting paid. Figure out how to take money as fast as possible
with the least friction. If you have auth and the ability to take money easy,
pivots come a lot easier too. Since you have proper auth, things like
subscription management becomes an easy reality without leaning on 3rd party
vendors. Though just using stripe for that can be good enough, still you'll
need to tie it to accounts. Especially if it's enterprise.

Something I've done recently that is now a part of my "get started fast" kit
is automated DNS and TLS (via letsencrypt) with kubernetes. Might not be for
everyone, but now that I'm on the other side, I'm not going back. I can tie a
feature branch deploy via helm chart to it's own DNS endpoint defined as the
host in the config, protect the ingress via LDAP, and make sure QA has an
endpoint to review that won't be interrupted until the ticket is closed. One
command and it's deployed and secure. Also this enables devs to deploy their
own workspaces for effortless experimentation without disrupting
dev/staging/prod, which shouldn't be used as sandboxes for features or QA IMO.

* [http://www.jumpcloud.com](http://www.jumpcloud.com)

* [https://www.keycloak.org/](https://www.keycloak.org/)

* [https://github.com/kubernetes/charts/tree/master/stable/exte...](https://github.com/kubernetes/charts/tree/master/stable/external-dns)

* [https://github.com/kubernetes/charts/tree/master/stable/cert...](https://github.com/kubernetes/charts/tree/master/stable/cert-manager)

* [https://github.com/kubernetes/charts/tree/master/incubator/k...](https://github.com/kubernetes/charts/tree/master/incubator/keycloak-proxy)

------
scarface74
#Tl;dr; Build relationships first, then build a reputation for your expertise,
_then_ implement changes.

Just for context, I’ve been working as a professional software developer for
22 years, but I let my career and knowledge stagnate until 2007 and became an
“expert beginner” ([https://daedtech.com/how-developers-stop-learning-rise-of-
th...](https://daedtech.com/how-developers-stop-learning-rise-of-the-expert-
beginner/)). I relaunched my career 11 years ago this month. So, how I’ve
approached “what to change”, changed over the years...

2007 - started working at a small company. I took the job because they were
looking for high level junior developers and were transistioning from VB6 to
C# and they had a C++/MFC framework. It was the perfect position for me. I was
really good at both their old technology and I was just getting into C#.

I didn’t try to change anything. I took the job to get some real world modern
development experience and soaked everything in.

2011 - that company went out of business but by then, I knew C#, I could talk
the talk about modern software engineering practices but I still needed more
experience. I got a job at a Fortune 10 (at the time) company and learned how
modern large software teams and organizations worked and was there to learn,
not to change things. I took what I learned and leveraged it and my by then 20
years of on paper experience to get a job where they wanted someone to make
significant changes to a slow moving dysfunctional software development
department....

Again: My goal wasn’t to make changes, it was to keep my head down, not ruffle
feathers and learn.

2014 - With both my manager’s and his manager’s blessing, I along with the
other developers they hired, went in and started trying to make changes in the
CI/CD process, getting rid of some bespoke custom libraries that could be
implemented better using popular Nuget packages, and changing the testing
process like bulls in china shop completely disregarding the feelings of the
old guard. Eventually the old guard won, pushing both managers out and leaving
the new hires without any cover.

Lessons learned: Build relationships first, respect the past decisions that
got the company to where it is, and remember one of the “Laws of Power”, “Law
45: Preach the Need for Change But Never Reform Too Much at Once”. Try to win
people over based on building relationships.

2016 - I started working at a new company with the official title of “Team
Lead” where I was brought in to modernize the development department. I
learned my lesson, first I built relationships, I respected the work the team
did, engendered respect, and earned the loyalty of the team. Even though I had
role power, I realized that wasn’t going to be effective without the
relationship power.

I implemented version control, a real CI/CD process, automated testing,
documentation standards, fought to reduce needless meetings and fought for the
“40 hour work week”.

2017: I got another job at a small company as “just” a senior developer and an
equal on paper. I quickly started building relationships and proving my
expertise. I have far more influence to make changes based solely on doing
that than I have ever had before.

Automation is always my hobby horse. First I implemented a sane CI/CD process
and configuration management.

The next thing I’ve worked on is getting rid of single points of failure in
both systems and people - I’m encouraging cross trainings.

------
stealthmodeclan
1\. Every now and then we run into Paywall. Give everyone employee debit card
so that they can buy stuff which helps their productivity.

2\. CI using Drone.io

3\. Add trello

4\. Everyone gets their own AWS account. It makes it trivial for them to
experiment with new ideas from their home or at office without begging anyone
for credentials.

You start by empowering your employees.

Now, we consult startups which work differently so you might not have capacity
to make these changes.

~~~
izolate
Do you have a list of companies you consult for by any chance?

~~~
readhn
haha. seriously?

------
macht
I go from git to SVN. It's just easier for me to work with and once the team
gets used to it, it's a win-win.

~~~
aetherspawn
SVN is really heavyweight for branches and tags. It used to take like a minute
to branch with SVN but when we swapped to git it took like less than a blink.

Also —rebase is way better than merge. I haven’t had to merge git for over 6
months but with SVN I was doing it twice daily, at least.

~~~
vijucat
If you use a repository URL rather than a local filename / dirname in svn
copy, it's a purely remote copy and is instantaneous:

$ svn copy file:///var/svn/repos/test/dir1 \
file:///var/svn/repos/test/dir1_jira_1886 -m "For bugfix to SERV-1886"

[http://svnbook.red-
bean.com/en/1.7/svn.branchmerge.using.htm...](http://svnbook.red-
bean.com/en/1.7/svn.branchmerge.using.html)

[https://svnvsgit.com/](https://svnvsgit.com/)

~~~
aetherspawn
Most of our team just used Tortoise SVN and the right click -> branch explorer
integration. We definitely were not pros at source control.

~~~
vijucat
Ah, I see! Tortoise SVN is great for the scenario where business users can
learn and use revision control, too, but I guess once you're doing branching
using Tortoise SVN, you're in a weird territory where you're pro, but not to
the extent you're ready to use the command line...

