Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

How to survive the first weeks as a developer in a fast growing startup?

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!

  • Be the first to comment

  • Be the first to like this

How to survive the first weeks as a developer in a fast growing startup?

  1. 1. HOW TO SURVIVE THE FIRST WEEKS AS A DEVELOPER IN A FAST GROWING STARTUP? STEFAN ADOLF
  2. 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. 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. 4. LET’S MAKE IT PERFECT.
  5. 5. WEEK 1-2
  6. 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. 7. UNDERSTAND AN UNDOCUMENTED CODE BASE
  8. 8. DEBUGGER
  9. 9. USAGE SEARCH
  10. 10. GIT BLAME / GIT LOG
  11. 11. APPLICATION LOGS
  12. 12. GENERATED UML
  13. 13. DATABASE REPRESENTATION
  14. 14. READ THE CODE. THEN READ IT AGAIN. THEN: GIT LOG. TEXT
  15. 15. USE THE TERMINAL, LUKE! EST’D 1971, MUCH FASTER THAN FINDER
  16. 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. 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. 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. 19. WEEK 2-4
  20. 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. 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. 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. 23. YOU’RE NEVER THE WISEST ELEPHANT IN THE ZOO. WEEK 2-4
  24. 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. 25. CODECEPTION TEST WITHOUT KNOWING ANY CODE
  26. 26. WEEK 2-4 CODECEPTION ▸ test real pages or APIs from the client side ▸ google-chrome-driver: no need for selenium or PhantomJS
  27. 27. WEEK 4-8
  28. 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. 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. 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. 31. DONE IS BETTER THAN PERFECT. TEXT
  32. 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. 33. KNOW YOUR SERVERS GO DOWN BEFORE THEY DO.
  34. 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. 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. 36. WEEK 9-12
  37. 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. 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. 39. APPLICATION PROFILING
  40. 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. 41. MOST PERFORMANCE ISSUES CAN BE SOLVED USING MONEY OR CACHES TEXT
  42. 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. 43. YOU’RE NOT THE FIRST ONE WITH THAT IDEA! TEXT
  44. 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. 45. TL;DR
  46. 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. 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

    Be the first to comment

    Login to see the comments

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!

Views

Total views

647

On Slideshare

0

From embeds

0

Number of embeds

148

Actions

Downloads

8

Shares

0

Comments

0

Likes

0

×