Productivity and learning on the job

Managing your time and focus, using AI assistants responsibly, and learning the domain as well as the code.

What: Knowing which of your tasks matters most this week, usually from your team's goals and your manager, and doing that first.
Why: Juniors are often busy with the wrong things. When two requests clash, ask which comes first instead of guessing.

Watch out

Saying yes to every small request and never finishing the ticket you were actually given.

Also called deep work, maker time

What: Protected stretches of one to three hours without meetings or chat, used for the hardest thinking work.
Why: Programming needs uninterrupted attention; many short gaps between meetings produce little real progress.
Example: Block two mornings a week in your calendar, set chat to do not disturb, and tell the team when you will check messages.

What: Moving attention between different tasks, messages and meetings, each switch costing time to get back into the problem.
Why: Fewer tasks in progress at once means each one finishes sooner. Batch small replies instead of answering every ping.

What: A routine for when you are blocked: restate the problem, reproduce it, read the error fully, shrink the case, check logs and history, then ask.
Why: A method keeps you moving and gives you a better question if you still need help.

Watch out

Changing code at random until the error goes away, without knowing why.

Also called acceptable use policy, Copilot policy, AI policy

What: Your employer's rules on which AI assistants you may use, with which data and code, and whether AI-written code must be marked or reviewed.
Why: Pasting company code or customer data into an unapproved tool can breach your contract and data protection law.

Watch out

Using a personal AI account on company code because everyone else seems to.

Also called AI output

What: Reading, understanding, testing and owning every line an AI assistant suggests before it goes into a pull request.
Why: You are responsible for the code you submit. Reviewers notice when an author cannot explain their own change.

Watch out

Submitting code you do not understand because it passed the tests you also asked the AI to write.

Also called NDA, confidentiality, confidential data

What: Source code, customer data, credentials, plans and internal documents that you agreed to protect when you signed your contract.
Why: Leaks, even accidental ones, can end a job quickly. Keep work data on work systems and ask when unsure.

Watch out

Pushing work code to a personal public repository to show in your portfolio.

What: Understanding the business area your software serves, such as payments, logistics or health, its terms, rules and users.
Why: Engineers who understand the domain make fewer wrong assumptions and are trusted with bigger problems sooner.
Example: Keep a glossary of business terms as you meet them and ask a product manager or support person to explain a typical customer day.

Go deeper