Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Ask HN: What is the first thing you implement at a new company?

news.ycombinator.com

Post reply on HN
Print view View original

51–60 of 293 posts

Re: Ask HN: What is the first thing you implement at a new company?

#51

Post by 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... or Paul Graham "Make something people want": 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...

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 & 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 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 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 (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 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 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

- 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

- 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-... "weekly" should be the minimum user-testing cycle. No "excuses" to not test! Use online services like 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.

Re: Ask HN: What is the first thing you implement at a new company?

#54

Post by iopuy »

systemtest wrote: post #45
colinbartlett wrote: post #22

Earlier quoted context omitted.

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.

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.

Agreed, it should be part of the standard technical on-boarding process. Once someone is familiar with what the editor is buying them in terms of productivity they are free to search for their own should they choose. A pet peeve of mine is joining a new team and asking what the editor of choice is to be told "really it is up to you."

Re: Ask HN: What is the first thing you implement at a new company?

#56

Post by dboreham »

cncrnd wrote: post #29
Jayvino wrote: post #14

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

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

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

Re: Ask HN: What is the first thing you implement at a new company?

#57

Post by PurplePanda »

systemtest wrote: post #45
colinbartlett wrote: post #22

Earlier quoted context omitted.

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.

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.

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.

Re: Ask HN: What is the first thing you implement at a new company?

#58

Post by dboreham »

mattlondon wrote: post #42
fastbeef wrote: post #6

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…

+1 for this. Unless you've been hired specifically to help them change their dev practices, I'd go along with what they have until you've got some understanding and reputational-clout to start suggesting such huge changes to how everyone works. Rocking up and on day one start asking people to change their development practices (particularly around branching policy which is something very contentious and/or strict eve…

The fact that process is off in the first place indicates a deeper problem.

Re: Ask HN: What is the first thing you implement at a new company?

#60

Post by cimmanom »

PurplePanda wrote: post #57
systemtest wrote: post #45

Earlier quoted context omitted.

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.

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.

Agreed. Plus now many editors obey the same .editorconfig files; and for those that don't, .editorconfig can be used as a reference for developers to configure their own working environment.

I can understand wanting to standardize in a company with a 1000-person engineering org, where maybe it's harder to enforce that everyone uses the same conventions if there's no standardization in tools; but in a team of a few dozen, you should only be hiring people you trust anyway, and communicating with them about why small things like this are important.

Post reply on HN