FAO Programmers/Developers - What's it like where you work?

[BlackDragon]

Hi All,

I'm interested to know what programmers and developer's working environments are like, and if things generally run smoothly, etc.

I graduated a couple of years ago, and I have been in this job for two years. I have become increasingly frustrated with where I work. I don't know if this is because I have unrealistic expectations of how software companies work and that this is how things are at any company, or if this place is as bad as it seems and it is time to jump ship to save my sanity.

I feel I spend more time dealing with obstructions rather than actually being productive, senior team members in team and company who are difficult to work with and untouchable, huge amounts of functionality with no documentation and the authors have long gone, unfunctional dev environments, and resistance from many to spend time improving things.

I'd appreciate it if people could share their experiences of their workplace.

 

[HangTime]

I'm not a programmer but that sounds like a lot of software companies.
In theory because we use Scrum (ish) dealing with obstructions isn't dealt with by developers, but it doesn't always work that way.

 

[UK-AL05]

Hi All,

I'm interested to know what programmers and developer's working environments are like, and if things generally run smoothly, etc.

I graduated a couple of years ago, and I have been in this job for two years. I have become increasingly frustrated with where I work. I don't know if this is because I have unrealistic expectations of how software companies work and that this is how things are at any company, or if this place is as bad as it seems and it is time to jump ship to save my sanity.

I feel I spend more time dealing with obstructions rather than actually being productive, senior team members in team and company who are difficult to work with and untouchable, huge amounts of functionality with no documentation and the authors have long gone, unfunctional dev environments, and resistance from many to spend time improving things.

I'd appreciate it if people could share their experiences of their workplace.

There are a lot of companies like this, but don't fret!. There is the odd exceptions, next time you go for interview check if they have a proper methodology in place, have bug trackers, encouraged to document, code reviews, source control, quality control software, use unit tests, continuos integration etc

 

[UK-AL05]

I'm not a programmer but that sounds like a lot of software companies.
In theory because we use Scrum (ish) dealing with obstructions isn't dealt with by developers, but it doesn't always work that way.

I know scrum quite well, and I have no idea what you just meant. The scrummaster really should be a senior dev via past.

Also you can't just pick and choose which parts of agile you use, misused agile methodologies can quickly turn into a mess. In fact there quite rigorous methodologies.

The biggest problem I found in unproductive places is people don't really know the process very well, thus you have to nag people to get things done with constant emails. I used to have email a graphic designer every 10 minutes, it was really annoying.

 

[BlackDragon]

We use scrum and try to be agile, but it seems like it's all talk as we don't make a focused effort to do it well. Seems like we pick and choose what we want to follow and hope it gives us the benefits but it doesn't.

 

[Deleted member 66701]

It's the same where I work and it's the same in most companies.

 

[UK-AL05]

When some people say agile they really mean, we just cowboy code and call it agile

 

[sloth]

It's the same where I work and it's the same in most companies.

Agreed.

And for huge amounts of code without documentation, we've got around 1.5 million lines of code with no supporting documentation at all, just half baked comments.

 

[HangTime]

What I mean is that the blockages should be removed by the scrummaster, irrespective of whether they used to be a senior developer in the past or not (they should in theory be a dedicated scrum master rather than sharing the role with development).

I know that Scrum should be applied rigorously, I know most of the theory, I'm a certified ScrumMaster myself, have worked in agile teams and have studied agile methodolgies at post-graduate level. I just felt it worth mentioning that at my organisation, we don't follow scrum religiously, different teams adopt different approaches, because it would have been misleading to suggest that my organisation uses Scrum. I'm not suggesting it is a good thing that we work the way we do, it's just a fact.

Finally the idea that you can't pick and choose parts of agile runs against the way in which some methodologies have developed - if everyone stuck to the same way of working, we'd never see any progress in the field. Again - not suggesting that it would be a good idea for organisations to deviate from a methodology they are trying to use, just that the idea that somebody somewhere can't make minor improvements to it, almost goes against principles in itself because it would have an inherent implication that the adopted metholodgy is perfect and that we shouldn't ever revaluate our position during the course of development.

 

[Randomface74]

Basically the same as my place, very chaotic. I'm a senior developer in a company that has grown very quicky, such that very few people have sufficient knowledge of the system to work on it. I spend most of my day fielding questions, training people, and so on.

 

[UK-AL05]

What I mean is that the blockages should be removed by the scrummaster, irrespective of whether they used to be a senior developer in the past or not (they should in theory be a dedicated scrum master rather than sharing the role with development).

I know that Scrum should be applied rigorously, I know most of the theory, I'm a certified ScrumMaster myself, have worked in agile teams and have studied agile methodolgies at post-graduate level. I just felt it worth mentioning that at my organisation, we don't follow scrum religiously, different teams adopt different approaches, because it would have been misleading to suggest that my organisation uses Scrum. I'm not suggesting it is a good thing that we work the way we do, it's just a fact.

Finally the idea that you can't pick and choose parts of agile runs against the way in which some methodologies have developed - if everyone stuck to the same way of working, we'd never see any progress in the field.

I also professionally qualified with some agile methodologies, and project management(prince2). At my old place it started with agile, everyone excited. Then slowly overtime it slowly degrades, you end up never doing any of the real phases/increments in a proper fashion(Because its boring), making sure documentations update, checking unit tests are update and it slowly degrades into cowboy coding. Yet they still think its agile. You try to say guys, were a bit off course and yet they don't care. They see it as overhead rather than keeping the project maintained.

 

[BlackDragon]

HangTime, would I be able to contact you in private? I'd like to ask some advice from you regarding how to use scrum effectively.

 

[UK-AL05]

http://www.techmanageronline.com/2010/06/agile-development-and-selective.html Pretty much describes it.

 

[HangTime]

HangTime, would I be able to contact you in private? I'd like to ask some advice from you regarding how to use scrum effectively.

I'm no guru and my organisation doesn't use scrum particularly effectively IMO
www.scrumalliance.org is a good place to start if you want more information about it.
I had training from this guy and thought he was exceptional, probably the best trainer I've had for any IT related course: http://www.scrumalliance.org/profiles/23-geoff-watts

 

[scorza]

Hi All,

I'm interested to know what programmers and developer's working environments are like, and if things generally run smoothly, etc.

I graduated a couple of years ago, and I have been in this job for two years. I have become increasingly frustrated with where I work. I don't know if this is because I have unrealistic expectations of how software companies work and that this is how things are at any company, or if this place is as bad as it seems and it is time to jump ship to save my sanity.

I feel I spend more time dealing with obstructions rather than actually being productive, senior team members in team and company who are difficult to work with and untouchable, huge amounts of functionality with no documentation and the authors have long gone, unfunctional dev environments, and resistance from many to spend time improving things.

I'd appreciate it if people could share their experiences of their workplace.

Sounds like you have a good opportunity to make a name for yourself putting some of those things right.

Right now for me things are pretty good, we have a stable team that's been together for a few years, a Project Manager who I have a lot of respect for, there's lots of work to do but we're all capable of doing it and don't need much in the way of direction. Only thing I'd like to change is that there isn't any paid overtime. Sadly this is going to change as our project comes to an end and the team breaks up, I'm sure the next project will be worse

 

[BlackDragon]

For those who try to use scrum, how do you divvy up the team members in scrum teams? How long do you keep the team together for? Do you let them specialise in certain areas, or try and get them working on as many parts of product as possible?

 

[AGD]

Only been working for a week but everything seems to run smoothly.

 

[uv]

One week in my current place, and I've never seen so much documentation! There's documentation for everything you can imagine

 

[Mr^B]

Been at my current job for 3 years, we use scrum (I'm also a certified scrum master, not that it really means much IMO) and it's pigging hard work compared to the usual Prince2/Waterfall I had been using for the previous 8 or so years (and SSADM before that).

I feel I spend more time dealing with obstructions rather than actually being productive, senior team members in team and company who are difficult to work with and untouchable, huge amounts of functionality with no documentation and the authors have long gone, unfunctional dev environments, and resistance from many to spend time improving things.

Quit and move somewhere where they are at least interested in fixing some of these things. If there's resistance to change, they're dead in the water. And *NEVER* be afraid of quitting if the environment isn't right.

If there were loads of things wrong, but a desire to fix them, then that can be as rewarding (or possibly moreso) than coming into an already functioning development team.

But in this case, and after two years, I'd give up and move on.

We do well on the Joel test (11/12) just fall down on the quiet environment, but that goes with the territory sometimes and you just need to come up with some coping strategies (headphones usually).

 

[Evilpaul]

I used to work in the defence industry where the V model is king and many innocent trees are murdered for the endless reams of documents that need to be produced.
It was actually a nice working environment, and I'd say that defence is one of the few industries where a V model is actually feasible. As each point on the V model was a deliverable to the customer, and usually a related payment milestone, then it was incentive to make sure it was all done according to the plan.
While it may ensure quality of the product (*quite* important for hard real-time products), it does mean that the projects have huge time scales.

I've since left the defence industry and for the last 3 and a bit years I've been doing automotive infotainment projects, quite a change of environment. The short time scales (6 to 12 month product cycles) present a different challenge, and working in a small team means we all get to do a bit of everything.
It can get a little wild, but we make sure that every so often we sit back and take stock of anything that has been missed and do a week of 'catch-up'.
It's not the ideal development environment, but at least for the moment it works for us. Although I'm trying to think of ways to push the team towards more defined process without getting lumbered with the job of managing it. I'm too much of a code monkey to want to get my hands dirty in management