Developer Productivity
When you have a team of 5 people who are all very productive, it's a great experience.
When you have a team with 4 productive developers and one who is not, it has many negative impacts.
Others feel it's not fair.
Others feel that this person doesn't belong there.
Others might feel they shouldn't try hard too and suddenly you have a team with 3 productive devs and 2 who are not productive.
In general, everyone should be productive. New people learning everything get 2 months to learn. People who have serious personal issues should be helped when possible. Yet, we are in a business of value creation for our customers. Productive work is win for you - win for us - and win for our customers.
What should you know?
Becoming a good developer is difficult. Honestly, I believe it takes about 10 years to become one. Some of that might be done during your teens and studies. Some of that must be done when you do development job.
The whole field of web app development is massive. You will never know everything. And we expect you to know a lot.
- HTML to the point you can create a simple layout, form, Datagrid
- How to upload files in HTML
- How to process it on a server
- How to SSH to the server
- How to write simple bash script
- How to kill Linux process
- HTTP codes
- Structure of HTTP requests and responses
- API design guidelines
- Basic coding with CSS
- Some CSS framework (Bootstrap or TailWind most likely)
- How to send HTTP request from browser
- What happens when you press Back in browser
- How to protect form against CSRF
- How to design database
- How to explain query
- How to create indexes
- SQL JOINs and aggregate functions, and string, date, money functions
- Basics of caching
- How e-tag works
- How to hash passwords
- How to work with cookies, user sessions, local storage
- What happens when app gets offline and has some basic knowledge of how to make app work offline
- Database migrations
- Database transaction isolation levels
- MVC and other design patterns
- Git basics
- How to use at least one editor/IDE really well
- How to validate data on backend and frontend
- How to parse JSON, XML, XLSX
- How to generate JSON, XML, XLSX, PDF
- How to set reverse proxy
- How to debug app in browser
- How to write backend tests
- How to write frontend tests
- Understand CAP theorem
- Write a simple parser for messy HTML/other text data
- Write simple ETL script
- How to make CRUD for database table really quick
- Write simple ETL script
- How to make CRUD for database table really quick
- How to implement sign in, sign out, forgotten password
- How to send e-mail
- What browser engines are now widespread
If you don't know one or more things on this list, please study that.
Delivering tasks
It's simple. Commit daily, push daily, and close tasks. Do not focus only on tasks in the backlog, focus on what's important. In that case, you might not deliver any Stories in a given week. Unless the person has non-development responsibilities, this shouldn't be something that happens all the time.
Pair programming
Ask others to pair with you.
Propose others to pair with them.
Pair programming has multiple different dynamics. Senior teaching junior, two seniors quickly building a feature that must be released today, two juniors trying to grasp a new codebase and do their first commits. All of that is supported and expected.
Review code fast
When you develop a feature, the code and the context are in your CPU cache.Later in the day, it moves to your RAM.Tomorrow, when you already working on something else, it's on the HDD.One week later, the code you wrote is as far as one-week-old files in your Downloads folder.
Getting back to the code you wrote is time-consuming. The fresher code for you, the faster you can make another iteration.
So please, every day do a review of all PRs of all other team members. First thing in the morning, review PRs there. You are improving your colleague's productivity and you also build a culture of accountability and mutual help
Treating underperforming team members
Sometimes people are not the right person for the job. It doesn't mean they are automatically bad people. They could be excellent team members elsewhere.
For us, it helps a lot to keep only people who work well with others who put in the right effort, and who are honest.
For people, it helps a lot to have a job that's not there just for money. Developers are builders. They should build something great. If they cannot build great things here, they should build them elsewhere. It's a win-win.
Sometimes people might be dishonest, track hours that aren't worked on, or even try to have multiple jobs at the same time. Please, let's not tolerate this behavior here. We don't delete people's worked hours from our systems. We pay everyone 1st or 2nd of the month before we are paid by our customers (sometimes months later, sometimes never). We want only honest people here.
Join Our Webinar!
Automatic Backend with PostgREST. Xiana + PostgREST shared JWT token
Discover how PostgREST automates backend tasks by effortlessly generating a REST API from your PostgreSQL database, saving valuable time and resources.
22
May
06:00 PM
CET