1. This site uses cookies. By continuing to use this site, you are agreeing to our use of cookies. Learn More.

Dealing With Pressure

Discussion in 'The Lounge - Off Topic' started by Ultra_Tech, Jul 10, 2014.

  1. Ultra_Tech

    Ultra_Tech New Member

    Hello All

    Thought I could do with some advice on this one.

    How do you guys deal with pressure of deadlines at work and how do you stay focused throughout the day?

    For some reason at the moment, I don't feel like I am performing up to my maximum, I feel I am getting constantly distracted, I find it difficult to concentrate and as a result, I am not as productive as I should be.

    I'd be interested in particular to hear from anyone who codes for a living, I am not a developer, but I work in Application support for a software development company which means I spend a lot of time reading/analyzing/changing code (SQL 98% of the time)/dealing with application/database/webserver/sometimes even windows server performance-related issues.

    How do you guys deal with the tons of emails that come in, people asking you to handle "urgent" (it's always urgent) issues, especially when quite a few of the issues are in depth and involve days of investigation/analysis/corrective action.
    Last edited: Jul 10, 2014
  2. dmarsh

    dmarsh Terabyte Poster

    I've been a developer for 20 years.

    Generally a productive environment for a developer minimises interruptions, this includes emails and meetings.

    Many agile shops have a daily morning stand-up for this reason, it should leave most of the rest of the day free for the developers to code uninterrupted.

    Context switching frequently is unproductive whether its a computer or a human, arguably the effects are worse in humans.

    People are often most productive and enthusiastic when they can experience flow, by having interruptions you are breaking peoples natural thought process.

    I'm not really a fan of the 'application support' role, because it pretends that there is a category between support and development which I don't think should exist in most cases. How can an 'outside team' really have a good grip on the code base and know what needs to be done ? Why is it broken in the first place if the dev team shipped it, surely its their responsibility to fix ? etc

    Yes you get urgent tasks as a developer, but if the projects run correctly you shouldn't be running around like a headless chicken.

    Its normal for support to have to handle a large volume of calls and prioritise, but IT support don't normally code.

    So generally I'd advise not to feel pressure, you should feel productive and in control as a developer, not under pressure. If you feel under pressure you should take deep breath and approach the problem logically.

    If management are making unreasonable demands its generally up to you to tell them, this is why you have the stereotype of the grumpy programmer that has no people skills, but really often its necessary for technical staff to put non-technical staff straight on what is and what isn't achievable in a given time frame.

    Unfortunately the cult of management now means its common to be managed by people who have no appreciation for your job or industry. They are often not engineers, they have never built, fixed or designed ANYTHING in their life, so they are not qualified to weigh in on technical issues.

    Google has Engineers manage their engineers for this very reason, and other established professions like architecture, surgery, aerospace also follow this practice.

    In fact having people with little industry experience manage others is a recent 'innovation', that I think has been largely unhelpful in most businesses.
    Last edited: Jul 10, 2014
    Arroryn likes this.
  3. ivorylies

    ivorylies New Member

    You can’t control everything in your work environment, but that doesn’t mean you’re powerless-even when you’re stuck in a difficult situation. Finding ways to manage workplace stress isn’t about making huge changes or rethinking career ambitions, but rather about focusing on the one thing that’s always within your control: you.
  4. Josiahb

    Josiahb Gigabyte Poster

    ALCOHOL! The cause of and answer to all of lifes problems.

    Seriously though if your working in a busy helpdesk environment in can make life difficult as far as even feeling like you are staying on top of things. I provide 1st/2nd and 3rd line support to a variety of small and medium businesses and in my time doing this if I can give anyone any advice its this: TAKE A BREAK. Every hour or so take a step back and look at the whole picture, re-prioritise where you need to and don't be afraid to say no.

    Its incredibly easy to get bogged down in one or two issues and all of a sudden the days over and you feel like you've got nothing done. Sometimes the best thing you can do is set something to one side and let your subconscious handle it for a bit while you clear some of the stuff you can get done easily. Everyone always wants things NOW but sometimes they just need to understand that if they want it done properly they are going to have to wait their turn.

    In your case you've got the easy out on some things, unless you specifically support the servers your application is running on the moment it becomes Windows Server issue punt it to local support. You'll be happier and so will we. Nothing more frustrating than logging in to a server to find the apps guys have been playing with things!
    Certifications: A+, Network+, MCDST, ACA – Mac Integration 10.10
  5. SimonD

    SimonD Terabyte Poster Moderator

    This is what Kanban is for, it's about prioritising work and knowing what you're supposed to be working on that day, what dmarsh mentions is pretty similar to the way that Kanban works, essentially you have your standup, you discuss what you're working on that day and then perhaps later on have a session later in the day to prioritise up coming work, it's also why development teams work in sprints (in our place it's 2 week sprints), they know what they need to do for that sprint and carry on with it.
    Certifications: CNA | CNE | CCNA | MCP | MCP+I | MCSE NT4 | MCSA 2003 | Security+ | MCSA:S 2003 | MCSE:S 2003 | MCTS:SCCM 2007 | MCTS:Win 7 | MCITP:EDA7 | MCITP:SA | MCITP:EA | MCTS:Hyper-V | VCP 4 | ITIL v3 Foundation | VCP 5 DCV | VCP 5 Cloud | VCP6 NV | VCP6 DCV | VCAP 5.5 DCA
    WIP: VCP6-CMA, VCAP-DCD and Linux + (and possibly VCIX-NV).
  6. dmarsh

    dmarsh Terabyte Poster

    Kanban is part of a larger ecosystem of agile methodologies. Its basic task management and prioritization. Its pretty popular with most development shops these days.

    The problem is the guy is in 'application support', so by definition they aren't really development and don't have requirements, project plans, sprints, milestones, releases, or whatever you might associate with either more traditional or agile development.

    They seem to occupy a space between support and development, so its not clear to me what their roles and responsibilities should be.

    Non developers typically should not be changing code or configuration. In fact I'd even go further to say that if a database is a persistence layer for an application, its part of the application, including whatever stored procedures or SQL may exist.

    The view of an RDBMS as a shared resource that everyone can use to do OLTP is broken in most modern organisations, the database has become an abstraction ontop of the file-system for an application. As such the application owns the database and should shield direct access from users.

    This leads into other topics like SOA, too many DBA's still think they can create an enterprise wide data dictionary and that they can consolidate to one giant silo, the future doesn't look like that. The future is distributed services, and services are applications.
    Last edited: Oct 15, 2014

Share This Page