> For the complete documentation index, see [llms.txt](https://engineering.umh.app/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://engineering.umh.app/career/your-first-months.md). # Your first months What your first four months look like, and what you should be able to do by the end of them. Go through this page in your [weekly 1:1 with the CTO](/culture/our-week.md#id-1-1-with-the-cto): what you have done, and what was hard. ## Your first month: learn the business and the product In your first month, you learn the business and don't write production code yet. At UMH, a Product Engineer has a lot of freedom. Nobody "protects" you from business context or hands you a ticket list. You decide what to build based on business impact ([Product Engineer](/engineering/product-engineer.md)). That only works if you understand the business. ### First: shadow and help the Value Engineers **Shadow the** [**Value Engineers**](/culture/working-with-the-rest-of-umh.md#value-engineer) **at customers.** Our Product Manager can invite you to the weekly customer calls with the Value Engineers. At first, you only listen in the background. Later, you join the meeting as a normal participant. For each customer you follow, write down what they want to achieve with UMH: the business impact we have there, and [why they bought UMH](/product/who-we-build-for.md). Watch how they work with the Management Console: where they click, what they avoid, and which workarounds they use. Each of these goes on your [list](#write-down-everything-that-was-hard), and fixing one makes a good pull request in your second month. **Ask the Value Engineers where you can help.** Maybe they need templates written. Or they need to connect to a specific OPC UA server at a customer: you install that OPC UA server yourself and connect to it first. At the customer, that saves them time, because the connection is already tested. ### When the Value Engineers have nothing for you: use UMH like a customer **Connect UMH to each of these, and build a Grafana dashboard for each on the UMH Historian, one that a customer would build.** * [ ] Our Siemens S7 PLC. * [ ] Our Kepware. * [ ] Our Ignition. * [ ] Our Wago PLC, over OPC UA and over Modbus. We don't tell you much more on purpose, because the same happens at our customers. You have to ask where each device runs. Finding that out is a classic Value Engineer job, because many customers don't know the IP addresses of their own PLCs. Some of it is on the [Sales PLCs](https://app.notion.com/p/1c2eb44d85c380d6a9f0cb3e04440c40) page (Notion, UMH only). **You are done when the data points appear in the Topic Browser and each dashboard shows them through the Historian.** ### Write down everything that was hard You will struggle with a lot when you first use UMH. Part of that is on purpose: like at a customer, nothing is set up for you and nobody tells you where to look. That is normal. Anyone should be able to use UMH, so when you struggle, it is not a you problem. It is always a UMH problem. Put every problem you hit on a list. In your second month, you work through that list and make UMH better. ## Your second month: work through your list **Pick fixes from your list that change code in every part of the codebase at least once:** benthos-umh, umh-core, and the Management Console backend and frontend. If you skip one, you later get a task in a part you have never worked in, and don't even know how to set up a test environment for it. That would be awkward. You don't need to become an expert in each. **Start small, for example with a docs change or a small bug fix.** Even a small change takes you through a lot of our [engineering process](/engineering/development-process.md). We expect you to use LLMs to write code end to end, in our product and not only in small proofs of concept or side projects. If you haven't worked that way before, a small change is where you learn it. [How to build](/engineering/development-process/how-to-build.md) and [How to ship](/engineering/development-process/how-to-ship.md) describe how your fix gets to production. ## Your third and fourth months: your first project **Pitch a project of about six weeks as a** [**rollout ticket**](/engineering/development-process/how-to-decide-what-to-build.md#rollout-tickets) **and** [**own**](/engineering/development-process/how-to-build/tickets.md#rules) **it until it is** [**shipped**](/engineering/product-engineer.md#id-4-definition-of-shipped)**.** Plan roughly two weeks of coding. The rest is rollout and monitoring. Usually we give you a broad direction, and you find something within it that delivers business impact. Your pitches have to show that you understand our business, or they keep getting declined. --- # Agent Instructions This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com. ## Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation by asking a question. Perform an HTTP GET request on the following URL with the `ask` and `goal` query parameters: ``` GET https://engineering.umh.app/career/your-first-months.md?ask=&goal= ``` `ask` is the immediate question: it should be specific, self-contained, and written in natural language. `goal` is what the user is ultimately trying to achieve, the reason they need the answer. Sharing it helps GitBook give you a better, more relevant answer. A goal is most helpful when it describes the outcome the user wants rather than restating the question. For example, with `ask=how do I create an API token`, a goal like `automate deployments from our CI pipeline` lets GitBook tailor the answer to that use case. The response will contain a direct answer to the question and relevant excerpts and sources from the documentation. Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.