After a cumbersome journey of phone calls, coding interviews and video assessments with HR you made it through the recruiting process and there you are: day 1 at your new company has arrived. It only takes few hours for you to recognise: everything is a big mess and you landed right in the middle of it. The CI system alerts red but people still deploy to production. Dozens of duplicated refactoring tasks are piling in a poorly managed issue management system. Most of your colleagues don’t put down their headphones and you suddenly feel very lonely, wondering why the people that hired you a month ago already left the company. Chances are: you are now working for an enterprise that grows so fast that even you as a newbie has to take care of everything. I’ll introduce you to many “survival patterns” for developers in a tech startup that I have stumbled upon. Starting from “how to communicate with people that don’t talk” up to “how to know when your servers go down before they do” until “understand an undocumented code base” I’ll come up with tools and procedures that worked for me, were accepted by my colleagues and impressed my management. I’ll also give short introductions to tools and coding practices that will get you over the first weeks without melting your brain. But first of all: Keep calm and git log!

1. HOW TO SURVIVE THE FIRST WEEKS AS A
DEVELOPER IN A FAST GROWING STARTUP?
STEFAN ADOLF

2. YOU’RE LISTENING TO…
STEFAN ADOLF
▸ PHP, Java, JavaScript & a little go
▸ Señor lead developer at Locadi/
Check24 Berlin
▸ founded his own startup & worked
for 3 more + Samsung SDS, 3ys
freelancing experience
▸ Scrum, Node and Symfony
evangelist
▸ more work, less talk
▸ @stadolf (everywhere)

3. WHAT IS A
“FAST GROWING” STARTUP?
▸ “fast growing” != “huge scale” (yet)
▸ things go constantly and unpredictably wrong
▸ it has a sufficient funding for ~12 months
▸ there’s more than 1 developer in the team
▸ there’s at least 1 developer in the team that’s massively
overworked
▸ chances are: not everything is working perfectly

4. LET’S MAKE IT
PERFECT.

5. WEEK 1-2

6. WEEK 1-2
PROFILING, LEVEL 1: OBSERVE AND LISTEN
▸ who’s there for the longest time?
▸ who does most of the work?
▸ who knows all the things?
▸ who will support / distract you?
▸ who splits the team, who keeps it together?
▸ who can push/merge to master?
▸ who knows to get around system restrictions?
▸ who can you have a beer with? 🍺
▸ who has had a hangover after a drinkout night with the investors?

7. UNDERSTAND AN
UNDOCUMENTED CODE BASE

8. DEBUGGER

9. USAGE SEARCH

10. GIT BLAME / GIT LOG

11. APPLICATION LOGS

12. GENERATED UML

13. DATABASE REPRESENTATION

14. READ THE CODE. THEN READ IT
AGAIN. THEN: GIT LOG.
TEXT

15. USE THE TERMINAL, LUKE!
EST’D 1971, MUCH FASTER THAN FINDER

16. WEEK 1-2
TERMINAL SETUP: HELPFUL ALIASES
▸ alias ll=“ls -la”
▸ alias ..=“cd ..” && alias …=“cd ../..”
▸ alias gop=“cd ~/projects/myproj”
▸ alias tailapp=“tail -f /var/log/app/prod.log”
▸ alias sf=“bin/console”
▸ alias getdb="ssh prod 'mysqldump -uuser -p
somedb | gzip > dump.gz' && scp prod:~/
dump.gz .”

17. WEEK 1-2
TERMINAL SETUP: THE PROMPT
▸ Mac: ~/.profile, Linux: ~/.bashrc
▸ https://github.com/alebcay/awesome-shell
▸ https://github.com/magicmonty/bash-git-prompt
▸ http://ezprompt.net/

18. WEEK 1-2
TERMINAL SETUP: COMMAND COMPLETION
▸ git: https://github.com/git/git/blob/master/contrib/
completion/git-completion.bash
▸ composer: https://github.com/iArren/composer-bash-
completion.git
▸ Symfony: https://hauck.io/symfony-bash-completion-mac-
linux/
▸ Wordpress CLI: https://wp-cli.org/#tab-completions
▸ NPM: https://docs.npmjs.com/cli/completion

19. WEEK 2-4

20. WEEK 2-4
GET PRODUCTIVE
▸ ask for a meaningful feature to implement
▸ take responsibility for it until it’s rolled out.
▸ understand the existing coding culture
▸ write tests for code that wasn’t written by yourself
▸ actively question workarounds and understand the answers
▸ ask for an supervised deployment
▸ understand the company’s culture
▸ have lunch/dinner with a “stakeholder” and another developer

21. WEEK 2-4
PROFILING, LEVEL 2: DEVELOPER CHARACTERS
Doesn’t talk much, works on his own.
Delivers stuff that works but doesn’t play
well with others.
Shares the funniest cat memes first on
#random.
THE INTROVERTED
Always knows immediately what to do.
Creates a working prototype by next day,
Stops at 90% and tells others to “fix” the
rest.
THE MAZE RUNNER
thinks that all problems can be solved
with a major version update, a platform
or language switch or a new database
technology.
THE CLOUDHEAD
Draws 30 pages of UML.
Writes more tickets than code
Creates time tables, QA/test-plans and
communication strategies before writing
one line of code.
THE STRATEGIST

22. WEEK 2-4
DON’T MENTION ON EVERY OCCASION THAT
▸ the codebase is one big mess
▸ documentation is missing
▸ they didn’t follow a consistent code style
▸ It’s by far the most irrelevant rule of “clean” code!
▸ you know better ways to achieve things
▸ the chosen architecture won’t scale

23. YOU’RE NEVER THE WISEST
ELEPHANT IN THE ZOO.
WEEK 2-4

24. WEEK 2-4
ACCEPTANCE (E2E) TESTING
▸ test a project without having insights into the code
✓ simple to write, maintain, understand and run
✗ con: quite slow, needs full project setup
▸ ideal for smoke testing
▸ should be run as a separate test suite
▸ Codeception, Protractor (Angular), SauceLabs

25. CODECEPTION
TEST WITHOUT KNOWING ANY CODE

26. WEEK 2-4
CODECEPTION
▸ test real pages or APIs from the client side
▸ google-chrome-driver: no need for selenium or PhantomJS

27. WEEK 4-8

28. WEEK 4-8
PROFILING, LEVEL 3: TEAM SETUP
▸ feedback should always start positive.
▸ utilize weaknesses and strengths of your colleagues:
▸ assign introverts’ PRs to cloudheads and strategists
▸ they’ll integrate working code with architecture
▸ break down cloudheads’ ideas to workable tasks
▸ assign them to introverts to see if it could work out
▸ let maze runners deploy their code
▸ so they learn that breaking things comes at a cost.
▸ Goal: everyone can blindly trust each other and everyone improves

29. WEEK 4-8
START LEAVING YOUR MARK
▸ take review responsibility for pull requests
▸ refactor a component
▸ improve some process component
▸ e.g. send a Slack notification when deployment has finished
▸ dive into the headache issues
▸ scale & stability
▸ insights
▸ get things done: if your first task/project still hasn’t been rolled out:
dismiss it, delegate it or finish it.

30. WEEK 4-8
PULL REQUESTS AND CODE REVIEWS
▸ If it works, it’s good. If it doesn’t break anything, it’s better.
▸ prefer personal discussions over github review comments
▸ open a PR on top of the original PR
▸ favor rebase over merge whenever possible
▸ git checkout ——track origin/feature/123-feature
▸ git rebase -i master
▸ git push ——force
▸ deploy review apps and have your Product Owner test the PR
▸ tell them what they should take care of
▸ let an experienced developer test the review app
▸ he knows how to break things you’ve overlooked

31. DONE IS BETTER THAN
PERFECT.
TEXT

32. WEEK 4-8
NAMING BRANCHES
▸ quite good if you have lots of branches
▸ feature/1234-add-countdown
▸ bugfix/CR-5678-repair-mails
IMPLEMENTATION-SCOPE TICKET-ID SHORT-TITLE/ -
YOURNAME TICKET-ID SHORT-TITLE/ -
▸ quite good for small teams and iterative pull requests / reviews
▸ elmariachi/1234-add-countdown
▸ stefan/CR-5678-repair-mails

33. KNOW YOUR SERVERS GO
DOWN BEFORE THEY DO.

34. WEEK 4-8
APPLICATION ERROR LOGGING
▸ use logging libraries
▸ PHP: Monolog
▸ node.js: winston
▸ airbrake.io for frontend logging
▸ writing application logs as JSON simplifies the ingestion in
log services
▸ use the CRITICAL level only for horrible defuncts (only
eventually uncaught exceptions) and send emails when
they occur.

35. WEEK 4-8
KNOW YOUR SERVERS GO DOWN BEFORE THEY DO.
▸ send all logs from all machines to one platform to analyse them
▸ Log analysis platforms
▸ loggly, logz.io, papertrail, ELK
▸ Instance and uptime monitoring
▸ Pingdom, New Relic, PagerDuty, Munin
▸ avoid sending logs directly from your app.
▸ Use (r)syslog(d)
▸ sysout (captured by container)
▸ or file watchers instead

36. WEEK 9-12

37. WEEK 9-12
SUPPORT THE GROWTH
▸ actively start cleaning up workarounds and hacks that
slow you down.
▸ usually it’s cheaper to buy than to build
▸ you can still switch to your own solution later
▸ profile your app to find bottlenecks
▸ don’t trust only gut feelings

38. TEXT
REQUIREMENTS ENGINEERING
▸ teach your stakeholders to
▸ formulate precisely
▸ focus on low hanging fruits
▸ minimalize user stories’ content
▸ housekeep your scrum / kanban board
▸ listen frequently and closely to people working with your
software
▸ they love to be understood and appreciate the discussion

39. APPLICATION
PROFILING

40. WEEK 9-12
APPLICATION PROFILING
▸ xdebug: profiler that creates cachegrind files. Enable in xdebug.ini
▸ great for local development
▸ viewer embedded in IntelliJ PHPStorm
▸ qcachegrind for more information
▸ blackfire.io
▸ profile running web applications
▸ compare results
▸ plays well with PaaS / heroku

41. MOST PERFORMANCE ISSUES
CAN BE SOLVED USING MONEY
OR CACHES
TEXT

42. WEEK 9-12
I’VE SEEN PEOPLE WRITING THEIR OWN…
WEB SERVERS
it’s faster!
We don’t need all these
features!
That way we understand
what’s going on!
We can control security on
our own!
DEPLOYMENT TOOLS
I wasn’t able to ssh into our
live machine with
capistrano!
I needed to modify our
configuration file for the
stage!
I had to log what’s
happening during the
deployment phase
FRAMEWORKS
feature xyz wasn’t in all of
them!
The bootstrap phase took to
long!
The caching component
didn’t work well with NFS!
I know OO-design better
than Martin Fowler!

43. YOU’RE NOT THE FIRST ONE
WITH THAT IDEA!
TEXT

44. TEXT
IMPLEMENT A DEVELOPERS FIRST CULTURE
▸ developers know the product better than anyone else!
▸ so why shouldn’t they have the better ideas?
▸ don’t simply accept all user stories: Question everything.
▸ Find people that support you doing that and share your
opinion with them.
▸ good interfaces are a matter of evolution and out-of-the-
box thinking

45. TL;DR

46. TEXT
TAKE AWAY
▸ use the terminal and your tools like a boss!
▸ gather all logs to a unique place where you can analyse
them. Logging will save your life!
▸ use e2e tests to get a minimum of security
▸ if you’re wondering what part is slow: use profiler tools!
▸ profile your comrades and learn how to handle them
▸ take responsibility and go the extra mile!

47. THANKS FOR
SURVIVING!
Stefan Adolf
https://www.facebook.com/stadolf
https://twitter.com/stadolf
https://github.com/elmariachi111
https://www.linkedin.com/in/stadolf/
I am
https://github.com/elmariachi111/farodevday