Got To Glow

Updated September 2026: in 2020 I shared first impressions of the German series Dark on Netflix after a few episodes: very dark night scenes, an excellent score, and subtitles that did not match the English dub. I have rewritten it into viewing tips for anyone starting the series now, with no spoilers.

Dark is a German science-fiction series that ran on Netflix for three seasons, from 2017 to 2020. When I started it on an iPad, three things stood out immediately: night scenes so dim I sometimes thought the screen had gone to sleep, a soundtrack good enough that I switched to headphones, and English subtitles that did not match the English audio. Each has a simple fix.

Why is Dark so hard to see at night?

Much of the series is deliberately shot in low light, and many scenes take place at night, in caves or in rain. On a phone or tablet in a bright room, detail disappears. Watch in a darker room, turn off auto-brightness and raise the screen brightness manually. On a TV, a picture mode designed for films rather than a "vivid" or energy-saving mode shows far more detail in the shadows.

Should you watch in German or with the English dub?

German audio with English subtitles is the better choice for most viewers. The performances are stronger in the original language, and the subtitles are translated from the German script. The English dub is written separately to match lip movements, which is why dubbed audio and English subtitles do not line up word for word. If you prefer the dub, turn subtitles off or choose the closed captions made for it.

Is it worth using headphones?

Yes. The score and sound design carry much of the tension, and a lot of it is low and quiet. Headphones, or a decent soundbar, bring out detail that phone or TV speakers lose. On Apple devices with AirPods, spatial audio can add to it on supported content.

How do you keep track of the story?

Dark follows several families across different time periods, and the same characters appear at different ages. Many viewers find it helps to watch in fairly close succession rather than weeks apart. Netflix published an official interactive guide for the series, and fan-made family trees are widely available; use them cautiously, because many contain spoilers for later seasons.

Does it really drag in places?

In my first few episodes, some scenes felt stretched, and I reached for fast-forward. It is a fair criticism of the early pace. Much of that slower setup becomes important later, though, so it is better to push through the first season without skipping.

My 2020 notes were written with only a few episodes behind me. With the right brightness, the original audio and good headphones, most of my viewing complaints have a simple fix.

Keep reading

• 20W fast charging your Apple Watch: what is actually true
• Apple Watch Battery Drain: Find the Cause Without App Data
• DTH Android box or streaming stick: which one to keep

Updated September 2026: in June 2020 I described being assigned an opportunity where my manager and the onsite coordinator each gave me different tasks, leaving me with two task lists for one deliverable. I have rewritten it into advice on handling conflicting instructions from two leads.

On the first day of that opportunity, the onsite coordinator asked for a few slide changes and some coordination with other teams. It looked simple, and I committed to finishing the next day. The following morning my manager added his own set of suggestions, unrelated to the client's requirements. I now had two lists: one from the coordinator, one from my manager, and the two of them already clashed over small inputs.

Why do conflicting instructions happen?

Because two people feel responsible for the same outcome and neither owns it clearly. The onsite coordinator is closest to the client; your manager is accountable for you and your team's reputation. Without an agreed split, both give direction, and the person doing the work absorbs the conflict.

What should you do when two leads give different tasks?

• Write both lists down side by side and note where they conflict or overlap.
• Ask one question to both: "Which of these does the client need for this deadline?"
• Get a single priority order agreed in writing, ideally in one shared email or call.
• Finish the agreed list first, and park the rest.

How do you avoid being caught between two egos?

Do not carry messages between them. If your manager's suggestion conflicts with the coordinator's, put both people on the same email or call and let them settle it. Relaying one person's view to the other makes you the messenger for a disagreement that is not yours, and it usually arrives distorted.

What if your manager's tasks do not match the client's needs?

Ask your manager to explain how the task serves the client's requirement. Sometimes there is a good reason you have not heard. If there is not, the question itself often makes the task quietly disappear. If it does not, and you are told to do both, state the time impact plainly so the deadline is renegotiated rather than silently missed.

How do you prevent it on the next opportunity?

At kickoff, ask who is the single point of approval for the deliverable. Write it in the scope summary. When everyone knows whose sign-off counts, competing instructions become suggestions to be approved, not tasks you must complete twice.

Keep reading

• When the Client Changes the Plan: Handling Rework
• Running an Offshore to Onsite Handover Call
• Scoping a Service Request When Requirements Keep Changing

Updated September 2026: this 2020 post described a day of addressing review comments, only for the onsite team to announce the next morning that the client had changed direction and the whole solution needed revamping. I have rewritten it into practical advice for handling a client's change of plan without taking on endless rework.

In June 2020 the delivery lead and I spent a full day on review comments and suggestions from other teams, and sent the updated document back hoping for light edits. On the next call, within minutes, the onsite team told us the client had changed the plan and we would need to rework the entire solution and approach. Before that call ended, I said we would deliver the revised version, and that any changes after it would be owned by the onsite team. They agreed.

Why do clients change direction late?

Because their own decision-makers see the proposal for the first time, budgets move, or a competitor's offer shifts their thinking. Late changes are part of presales work. The aim is not to prevent them but to limit how many times the same document is rebuilt from scratch.

What should you do in the call where the change is announced?

• Listen and take detailed notes rather than reacting. The reasons behind the change shape the rework.
• Ask what stays the same. Parts of the solution usually survive, and naming them early saves time.
• Agree ownership before the call ends, as I did: who does the rework, and who owns any changes after it.

How do you make the ownership agreement stick?

Write it down straight after the call and send it to everyone present. A verbal agreement made in a tense meeting is easy to forget a week later, which is what tends to happen. In my case the onsite team accepted ownership on the call, and it still went the other way afterwards. A short email summary gives you something to point to when the next round of changes arrives at offshore.

How do you protect your team from repeated rework?

Build documents in modules, so a change of approach replaces sections rather than the whole thing. Keep each version, and mark which parts changed and why. When a third or fourth complete revamp is requested, the version history turns "we keep redoing this" into evidence your manager can use to renegotiate the effort or the timeline.

What is the lesson from that morning?

Saying clearly who owns the next round was the right instinct. Putting it in writing the same hour is what would have made it hold.

Keep reading

• Scoping a Service Request When Requirements Keep Changing
• Two Leads, Two Task Lists: Handling Conflicting Instructions
• Running an Offshore to Onsite Handover Call

Updated September 2026: in March 2020 I agreed, as a favour, to help an old delivery team with "a small request", and it turned into two days of back-to-back calls. I have rewritten it into advice on handling ad-hoc requests from past projects without losing your current work.

I had a good rapport with the delivery lead from a previous project, so when he asked for support, I persuaded my manager to allow it. Only after I was added to the main email thread did I see the size of it: a full day for one part, and two days of focus overall. I got it done through two days of calls and constant revisions, and told the lead afterwards that I could not keep taking ad-hoc requests like this.

Why do small favours from old projects grow?

Because the request is described from the requester's side, where the context is obvious and the effort feels small. You see the real size only once you have the full thread. By then you have already said yes, and your manager has already agreed on your behalf.

What should you ask before agreeing?

• Ask to see the full thread first, before committing time.
• Ask for the deliverable and deadline in one sentence.
• Estimate the hours yourself and share the estimate back.
• Agree a limit: "I can give you six hours this week" is a clear commitment; "I'll help out" is not.

How do you tell your manager?

With the estimate and the trade-off. If you persuade your manager to let you help, as I did, be clear what slips on your current work as a result. Managers who agree to a vague favour often feel misled when it turns into days.

What if it has already grown?

Stop and re-scope at the point you realise, not at the end. Tell the requester what is left, how long it will take and what you can realistically finish. Offer to hand the rest to someone on their current team with a short brief. Finishing everything through sheer effort, as I did, gets the work done but teaches everyone that your time is free.

How do you set a boundary without damaging the relationship?

Say it after you deliver, not in the middle, and keep it about your allocation rather than the person: "Happy to have helped close this. Going forward I will need these to come through my manager so they are planned." Good working relationships survive a clear boundary. They suffer more from quiet resentment built up over repeated favours.

Keep reading

• When the Client Changes the Plan: Handling Rework
• Two Leads, Two Task Lists: Handling Conflicting Instructions
• Managing Your Bandwidth When Several Teams Want You

Updated September 2026: this 2020 post captured my uncertainty after kicking off a presales request with a team I had clashed with before, not knowing whether the work would stay simple. I have rewritten it as a guide to scoping a service request so requirement changes are visible and manageable.

In February 2020 I set up the call between onsite and offshore teams for a new service request, gathered the requirements and felt relieved: most slides were standard, only a few needed rebuilding. By the next calls, as usual, the expectations had changed. The pattern is familiar to anyone in presales or solution work.

Why do requirements keep changing on service requests?

Because the client is often still deciding what they want while you build it. The onsite team hears new thinking on every client call, and passes it on as it arrives. Changes are normal. What hurts is when they are informal, so nobody notices how far the work has drifted from the original ask.

What should you confirm at kickoff?

• The purpose of the deliverable and who will present it.
• What already exists and can be reused.
• The exact list of new content needed, in writing.
• The deadline and any review points before it.
• Who on the onsite side can approve changes.

Send this back as a short summary after the call and ask for confirmation. It takes fifteen minutes and becomes the baseline for every later conversation.

How do you handle changes once work has started?

Log each one: what changed, who asked and when. Then state its effect in one line, for example "adds four slides; moves the draft from Wednesday to Thursday". This is not about refusing changes. It makes the cost of each change visible, so the onsite team can decide whether it is worth it, and so the final timeline surprises nobody.

How do you work with someone you have clashed with before?

Rely on process rather than goodwill. Agree roles at the start: who owns the client conversation, who owns the document, who approves. Keep communication in shared channels rather than side calls. Past friction usually comes from ambiguity about ownership, and a clear split removes most of it.

What if the scope keeps growing?

Raise it with your manager once the change log shows a clear trend, with the numbers: original scope, current scope, hours added. That turns a feeling of being overloaded into a decision someone above you can make. The uncertainty I felt in 2020 was really about not having that baseline on day one.

Keep reading

• When the Client Changes the Plan: Handling Rework
• Running an Offshore to Onsite Handover Call
• Two Leads, Two Task Lists: Handling Conflicting Instructions

Updated September 2026: in January 2020 I wrote about waiting for my hike after two years of top ratings, knowing a company rule required three years before promotion. I have rewritten it into a guide to tenure rules and how to make the case for promotion when they apply.

In early 2020 I had the top rating in my team for the second year running and had been recognised as a key player. When I thanked my manager and asked about promotion, the answer ran into a policy: an employee must complete three years before being considered. Two top ratings did not change that.

Why do companies have minimum tenure rules?

Large IT employers promote in batches with fixed budgets, and tenure rules keep the process predictable and defensible. They stop managers promoting favourites quickly and give HR a simple filter. The cost is that strong performers sometimes wait a year longer than their work justifies.

Can a top rating override a tenure rule?

Sometimes. Many companies allow exceptions or an accelerated promotion for exceptional ratings, but it usually needs a manager to push it through a formal process. It is worth asking your manager directly whether such a route exists and whether they are willing to use it for you. If they do not know, HR policy documents or the HR business partner will.

What can you do while you wait?

• Get the timeline confirmed: the exact cycle in which you become eligible, in writing.
• Ask what the next grade requires beyond tenure, and start doing that work visibly now.
• Negotiate the hike instead: a strong rating without promotion can still justify a larger increment or a one-time bonus.
• Keep evidence of work above your grade, so the case is ready the moment you become eligible.

When does a tenure rule become a reason to leave?

When the market already pays your experience at the next grade and your company will not for another year or two. A lateral move to another employer at the higher designation is common in Indian IT, and it often brings a larger salary change than an internal promotion. It is worth knowing what the market offers, even if you decide to stay.

How should you raise it with your manager?

Thank them for the rating, as I did, and then be specific: "I understand the three-year rule. Is there an exception process for consecutive top ratings, and would you support me through it?" A clear yes, a clear no, or a vague answer all tell you something useful about your next twelve months.

Keep reading

• Return to Office in 2026: What Three Days Actually Cost
• How To Cancel Any Subscription In 2026: State Rules Compared
• Buy Now Pay Later Refunds in 2026: Your Rights Compared