Hello and welcome to nerdgeschoss GmbH. This document is here to help you find your way around the company, gives you all needed contact data and a general overview on how we work.
How do we make decisions? What are our strategic movements build on? We tried to define six core values that we want to base our decisions on.
We strive to create awesome work that we can be proud of and others look up to. We never stop improving ourselves.
All heroes need guides. Help others achieve their goals. Empathise, care and challenge.
Donât create solutions for problems that do not exist. Ask better questions, listen and repeat.
Honesty is the foundation of good communication. Show trust and respect for each other by always choosing transparency over secrecy.
What makes you weird and special makes you memorable. And not only that, it makes you authentic and original. This is your superpower.
nerdgeschoss GmbH was founded in 2013 as a legal entity as a project of Christian and Jens. Before they worked as colleagues in a design agency. From the beginning we had a focus on apps, mobile and ux while the term responsive design wasnât even a buzzword yet. During the first years we focused on native and hybrid apps (iOS, Mac, Android) while spending the majority of time wrestling with Wordpress. In 2014 we joined a Startup called MyLane, trying to disrupt the point of sale of german local retail with iOS based point of sale systems. As it turned out this was quite a nice idea (as Square proved a bit later), but failed quite badly for us.
Recovering from this fail nerdgeschoss pivoted back to the initial idea: Doing serious applications instead of Wordpress pages and startups. We started taking Ruby on Rails as our main stack and extended it in 2017 to use React on the frontend, targeting companies from startups to bigger corporates. This is where our technical mission statement came from: Build solid and maintainable software that is focused on helping and delighting the end user.
You arrived at the office, signed your contract and probably already had your first coffee. Now the fun can start! After receiving your new MacBook and other hardware, you will get access to a lot of web based tools we use for collaboration.
The first thing that will happen. You get a Gmail invite for your personal [email protected] address. From now on please use this email account for all business related signups and conversations. This is an email account to document your work, so we reserve the right to have a look into it if we urgently need any info from it (just store your vacation bookings and loveletters in a private account, please đââď¸).
This invite also includes a Google Calendar. All calendars in the company are connected and public to each other. If youâre interested, you can add others from the web interface to your view (this also applies to Calendar on Mac/iOS).
n.U.T.S. stands for nerdgeschoss Unified Tech Stack, our common architecture for Rails applications. Itâs so amazing, it even has itâs own handbook page.
All collaboration happens in GitHub. We have a company account for both private repos for our customers and public open source repositories. You will be added to the developer team and therefore will have admin access to all repositories (this is intentional â waiting for an admin should never be a thing). More on how we use Git later.
This is where internal communication happens. Every project has its own channel. Also make sure to subscribe to #office to communicate with everyone in the office. More on the slack workflow later.
Our time tracker. Most of our projects are billed by time and material to our customers, therefore itâs important to track your time every day. We do not use the time tracker to check how many hours you spend in the office, but just to bill our clients (so please donât make up numbers here to look like youâre working more â we wonât see it anyway). You might want to install Harvest for Mac which allows you to start time tracking via hotkeys.
For entries, please make sure to use the format #123 - Title of Issue whenever possible so we can automatically generate invoices from them. This also helps in finding entries that accidentally get made for wrong projects.
If you survived the job application process you probably already touched Heroku. In our experience it is the easiest and most stable hosting solution we tried so far. We use it for everything from simple Wordpress to microservice-backend-apps. Have a look at Heroku Review Apps if you need more arguments for it. We use Heroku Flow as a development style. The rule is simple: Whenever you donât have an explicit reason not to go for Heroku, always go for Heroku and donât host it yourself.
The nerdgeschoss app contains everything company-related you might need at app.nerdgeschoss.de. Here you can check on your paychecks, remaining holidays or sprint performances. This app is open source and available in our GitHub account. Feel free to do pull requests to improve it.
This is where project management happens. There is a Sprint Board that contains everything that is currently being worked on with filters for each project. More about columns below.
Website ¡ iOS App ¡ Contains all passwords and software licences you might need. Ask Christian or Jens for access.
Website ¡ To interact directly with the database, we use TablePlus.
Website ¡ This is our preferred choice for development as it has the best developer tools.
Website ¡ Miro is our tool of choice for visual brainstorming and idea mapping. Whether we're sketching out database diagrams, crafting flow charts, ideating on virtual boards, designing wireframes, or plotting roadmaps.
Website ¡ We use Tower for all of our git operations from cloning repos to generating pull-requests. Unless you are a git master, we recommend that you use this too!
Website ¡ It's a design software!
Website ¡ It's a good, extensible code editor. And it's free! You could do worse than using this.
You got everything set up correctly? Time to get some work done!
Weâre here to help you grow and get the best work possible done. If we can support you in any way with that just let us know. This includes everything from drinks to software licences you might want to use or additional hardware.
At nerdgeschoss, fostering community is as important as our technical pursuits. As a remote-first team, we understand the value of face-to-face gatherings, and hence we've introduced our cherished tradition â Dumpling Dienstag đĽ.
Each Tuesday, our team gathers at a pre-specified location, often our office, for a lunch filled with delicous dumplings. It's a casual event that offers a breather from work, encouraging rich conversations and shared experiences.
This tradition isn't exclusive to our team. We believe in openness and welcome clients, friends, and family to join in the feast, enhancing the diversity of our interactions.
Invitations to Dumpling Dienstag đĽ are sent out weekly, ensuring everyone is free to join or skip based on their convenience. Even if you're remote, you're always welcome to join when in the area.
Please note, participation is entirely voluntary. Respecting personal choices and work-life balance, we aim to create a relaxed and social atmosphere. We hope to see you there, relishing the culinary delight that is Dumpling Dienstag đĽ!
For all employees the snack bar and drinks are free.
For credentials to our Wifi, check 1Password.
There is no calendar for the meeting room as of now, so itâs used on a first-come-first-serve basis. If you need to reserve the room for specific meetings, just let the others know via slack.
The meeting room has a 55inch 4k TV with an attached Chromecast or Apple TV, so you can mirror your screen or individual windows and tabs without installing additional software (although you need Chrome for the Chromecast).
On the other side of the room you will find a magnetic whiteboard and markers. If you use the board, please clean it after the meeting. Those markers have the nasty habit of becoming quite permanent over night and are super hard to remove the next day.
We pride ourselves on not only being remote-friendly, but remote-first. All processes are designed to support an asynchronous workflow across timezones that should help you to adapt work to your life â and not the other way around. There are no minimum office days, you can individually decide where to work.
Feel free to work remotely as much as you want; there is no minimum of days in the office. We have some recommendations for you though:
Feel free to switch between tables whenever you want. We try to keep all tables equipped with the same hardware so itâs easy to switch. If you feel like it, you can also work in the kitchen, on the couch or on the balcony. If you have long phone calls, it might be a good idea to switch to the meeting room or the phone booth to not disturb the others too much.
Work at nerdgeschoss happens asynchronously, there are no fixed working times. We believe that work should adapt to your life and not the other way around.
Nevertheless we have some rules to make working (especially across timezones) easier:
To simplify the planning of required team meetings, there is a Core Meeting Time from 9:30 to 12:00 (Berlin time). Do not schedule any other appointments and make sure that you are available during this time. This also includes any private meetings or doctor appointments (these can usually be scheduled to a later hour or if it's really urgent you of course can take a day of sick leave). This way we can schedule company wide meetings without having to schedule with each person individually.
Youâve done your best for today and itâs time to head back home and enjoy some time away from the keyboard. Before you leave please check some things:
After you left, donât bother with work. Your free time is yours, so you donât have to answer slack messages or emails (if we manically call you 15 times and leave hundreds of slack messages pinging you, it might be worth checking in with us though đ).
Overtime is neither expected nor seen as a good thing. Focus on the time during work, work efficiently during the day and use your free time to restore your energy. And if you still stay in the office we might kick you out at some time đŞ.
Every second Friday during Review we recap what we achieved during the sprint together. We discuss impediments and their solutions and how to continue during the next sprint. This is also the moment to showcase your work, present libraries and helpers youâve written during the week and give each other feedback.
Vacations and sick days are managed via the nerdgeschoss app.
As weâre all not machines, unforeseen things can happen. First things first: If youâre sick, stay home and take care of yourself. No one will be happy if you get worse by forcing yourself to the office â or worse: make your coworkers sick, too. So stay in bed and take care of your health.
Nevertheless there are some legal/organisational parts to this, too: If you are sick, tell us before the core office hours. If youâre sick for more than one day, we need a notice about this from your doctor from the second day.
Visiting doctors or related services during work times depends on the severity of your condition: You have a fever and canât breathe? Probably you shouldnât be in the office in the first place. Youâre going to your quarterly health checkup or yearly dentist appointment? Do this outside of work hours. We offer quite flexible core working hours, so it should be possible to shift your appointment accordingly. Keep in mind that time at the doctor is not working time (unless they write you a sick note, in that case itâs part of the sick time).
The following are guidelines to help you coordinate your work with your team. They are just general ideas and can always be adapted to specific project needs.
Any ideas and customer requests go first to the Shaping status and stay there until all external factors are determined and all open questions are resolved. This usually involves talking to the customer, creating mockups or doing user research, figuring out API documentation or deciding on props for a component. You have any ideas what you would like to change about a project? Throw it into the "Shaping" status.
Before any work on a sprint starts, it is time to shape all stories. To have a story shaped, make sure the following things are documented within the issue by posting a comment:
Shaping a story usually involves multiple people, e.g. a backend developer and a frontend developer working together, maybe even involving a designer to discuss behaviour of certain elements and components.
Once all of this is documented, review it together with another developer either in person, call or chat. Adapt the shaping comment until both of you are confident in the implementation. Then the reviewer should move the story to the Todo column.
All tasks in the task board in the âTodoâ column that are not assigned to a specific person can be worked on. If there is a task marked as âimportantâ, you should consider taking this one first. Also make sure to check if you can help your peers in a peer review before starting new work.
If you find something you want or need to work on that is not on the task board, create a task in the backlog and advocate to get it into the next sprint.
If inspiration strikes and you envision a potential enhancement to our projects, we welcome your input in our dedicated Ideas segment. Here, your innovative proposals can be articulated, discussed, and refined within our team. Following the consolidation of an idea, we will incorporate it into an upcoming sprint for further development. If your task list ever runs dry, feel free to delve into this section â your insights could help shape these ideas or facilitate their inclusion in the current sprint. We also encourage team members to bring forth these topics for discussion in our bi-weekly team meetings.
Pick the card and move it to the In Progress column and assign yourself. Next up, create an empty pull request (in status draft if possible) in the project. Your branch should be named feature/123_task_i_am_working_on - make sure to include the issue number. Give that pull request a descriptive name (âBug Fixâ is not descriptive!) and add either the ticket number or a proper description to this pull request (again, âfixing a bug in cardsâ is not descriptive!). The early pull request is there for your team to see what youâre working on and prevent duplicate work. To simplify the process, you can also use the pull-request gem which installs a pr command.
Your work is done, now itâs time to integrate it into the project. Have a look at your pull request in GitHub and check the following:
Before marking your task as ready for review, you should take some additional steps to ensure your feature is easily testable. Configure the review app as necessary and provide reviewer notes in the Issue. These notes should contain information that will assist in the review process, such as login credentials and specific instructions on what and how to test your feature.
When you're confident in the quality of your work, move the corresponding task to Review and mark your pull request as ready for review. If there's a specific coworker whose input you believe would be valuable, feel free to request a review directly from them using GitHub's review request feature. However, avoid making such requests for every PR as you don't want to overwhelm your colleagues' inboxes.
With your task now in the Review stage, the peer review process can begin in earnest.
Peer Review and QA happen in parallel.
This state is designed to have your code reviewed on a technical level. We use GitHubâs review feature to leave comments directly in the changed code. If you request a change, move the issue back into the Todo column.
Things to look out for as a reviewer:
Once you're done and everything is fine, approve the PR in GitHub.
QA means testing the feature once more before the end users see it. This happens in parallel with code review to not block each other.
Once you're done and everything is fine, approve the PR in GitHub.
When the pull request reaches the Peer and QA approvals, it is time to merge. The last person to approve a PR is responsible for merging into the main branch (usually with a squash commit) where itâs directly picked up by deployment scripts and deployed to staging/production servers. This also means nothing should be merged before it is finished, including translations, icons or other assets. Once the feature is released, move the issue to Done.
To create an inclusive work environment and reduce bias in salaries, we use the nerdgeschoss Human Growth Framework to determine salaries.