About the employment situation in the city

115 posts in this topic

On 10/28/2019, 5:15:55, MikeMelga said:

Yeah, but took me several years to get them, I had to get very strict during interviews. All new developers must be team players. Maybe this gets us back in topic? :)

 

I think what I am trying to explain you keeps flying over your head.   You see things from the manager point of view, nothing wrong with it, it is your job, but I bet if someone ask your employees in a situation they could be honest they will tell you a different story.

 

"Team Playing" encourages people to play by the unofficial cultural rules of the group, this might limit people who just prefer to play the game instead of causing disturbances.  Very experience employees tend to just give up and play the game, instead of calling for changes that will go against the culture of the group.  This is sometimes called "pick your battles", which can be either a bad or good thing.

 

I can understand of course your point, it is true there are people who are just permanent disturbances and they are either wrong, or they are right but they do not get it does not bring anything to the project/customer to implement their totally correct ideas. 

0

Share this post


Link to post
Share on other sites
On 10/29/2019, 10:45:14, MikeMelga said:

1) Being able to communicate ideas

2) Being receptive to other people´s ideas

3) Recognizing when a mistake was made

4) Able to cover for others

5) Being able to engage in constructive discussion

6) Accept to work on shitty tasks from time to time. Take one for the team!

7) When I´m at a customer in Asia, with a big problem to solve, with a huge time zone difference, show up at 7:00am in the office and help me out

8) Have empathy, i.e. be able to write code that others can understand

9) Be able to compromise

10) and so on...

 

Unfortunately to be able to do this, you do need some decent social skills. Empathy being one of the most important.

 

 

By your behavior here you are pretty bad at #2, #3, #8 and maybe #9.  

 

1

Share this post


Link to post
Share on other sites
1 hour ago, Krieg said:

 

 

By your behavior here you are pretty bad at #2, #3, #8 and maybe #9.  

 

#2 definitely. Been working on that for years. I have some tricks on how to do it in my team, and they work quite well. In the personal field, I don´t really bother.

#3 disagree, it is actually the contrary, I am not afraid to make mistakes, because I don´t "stick to the plan", as many people do

#8 completely disagree. The internet masks a lot of stuff, but definitely I have a lot of empathy

# 9 completely disagree, the hardest part of my work is to combine the requirements and timelines from all stakeholders. That requires, above all, capability of compromise.

0

Share this post


Link to post
Share on other sites
1 hour ago, Krieg said:

 

I think what I am trying to explain you keeps flying over your head.   You see things from the manager point of view, nothing wrong with it, it is your job, but I bet if someone ask your employees in a situation they could be honest they will tell you a different story.

That is why 2 years ago I created a monthly meeting (kind of a retrospective) where people can say what is and what is not working. I only go to the 2nd part of that meeting, to give them freedom to express themselves without my overwhelming presence in the room. The results are therefore anonymous afterwards.

0

Share this post


Link to post
Share on other sites
3 hours ago, zwiebelfisch said:

 

This is true, but I see it the other way around.  If you love your field and anyway spend all your spare time learning new stuff, programming at home, building cool stuff with your raspberry etc, then its the right career for you.  If you dont, then its not my place to tell you one way or the other, but odds are that you will see it as a chore.

 

But Id say that about almost any skilled role. If you arent interested in chemistry and dont want to spend your evenings reading scientific papers, you probably wont love your job as an HPLC specialist and if you dont want to spend your weekends marking homework you probably arent cut out to be a teacher.  

 

And to be honest, decent companies invest heavily in personal development, and view worklife balance as more than a buzzword.

 

I don't agree with that at all.  

 

there are plenty of things I sincerely love to do, software dev being one of them.  But none of them are interesting enough to spend ALL of my time on.  Dev is work.  It's not a chore, but I expect to get paid for the time I spend doing it.  Ergo I do it at work only, and do other things in my free time.  Never had any trouble staying up to date with new techniques or technologies with this method.  

 

2

Share this post


Link to post
Share on other sites
4 hours ago, zwiebelfisch said:

 

This is true, but I see it the other way around.  If you love your field and anyway spend all your spare time learning new stuff, programming at home, building cool stuff with your raspberry etc, then its the right career for you.  If you dont, then its not my place to tell you one way or the other, but odds are that you will see it as a chore.

 

But Id say that about almost any skilled role. If you arent interested in chemistry and dont want to spend your evenings reading scientific papers, you probably wont love your job as an HPLC specialist and if you dont want to spend your weekends marking homework you probably arent cut out to be a teacher.  

 

And to be honest, decent companies invest heavily in personal development, and view worklife balance as more than a buzzword.

 

Not sure if I am share this.  When I was young I spent lot of my free time in things related to technology, I was part of several free software programming, tinkered a lot with R-Pies, networking, electronics, etc.   But it was always a hobby.   Once I've got kids other things took priority and I stopped doing all that and I barely maintain my network at home and choose component that require the least tinkering as possible.    I have no problem keeping up to date at least with things that are related to my job because I can take the time to do that as work time and get paid for it.

 

We have one colleague who is still like that, still write and publish papers and research a lot in his private time.   And actually we think he kind of neglect his family because of it.  

1

Share this post


Link to post
Share on other sites
On 10/10/2019, 14:36:45, zwiebelfisch said:

 

 

A few additional factors that contribute to the mental issues/lack of social skills among people working in IT (but in general among office workers)

- This sadistic idea of "continuous improvement" required on people, so common especially in American companies. I'm not saying that it's a bad thing to improve yourself, but the way it's often presented is that...you're never good enough. Imagine what disaster this does to the subconscious of a person...

 

- This evil methodology called "Agile" (I would even call it ideology, since it's often applied blindly without any questions), which promotes a culture of stress, micromanaging and buggy software.

I've seen teams in different companies that had the following behavior: If a story was not completed during a Sprint (something totally normal and natural...there can be many valid reasons why this happens), they would close the story (so that "officially" they had completed it, and it looked good on the board), and create a new one in the next Sprint, which was basically a continuation of the previous one.

Another behavior that I've seen was rushing to code reviewing a few hours before the Sprint ends...colleagues begging to have the CRs approved, not matter if the code was of good quality or not. Because..."it doesn't look good if I don't finish the story".
I'm not looking forward to the day that this cancer will spread to software that controls nuclear power plans or airplanes.

- This other retarded idea of the "open office", which improves collaboration by 20%, but increases stress by 200%. Apparently now the same companies that were pushing so hard for it are backtracking (and buying overpriced phone boots), and they discovered...surprise surprise...that it reduces productivity.

0

Share this post


Link to post
Share on other sites
1 hour ago, UpToWick said:

This other retarded idea of the "open office", which improves collaboration by 20%, but increases stress by 200%. Apparently now the same companies that were pushing so hard for it are backtracking (and buying overpriced phone boots), and they discovered...surprise surprise...that it reduces productivity.

I worked in an open office environment for years, with up to 14 co-workers.  For our needs, which often crossed, it was very good for collaboration and for collegiality. Ultimately we were put into cubicles.  It was like being caged, though we weren't enclosed.  
Booths?  To me, that shows how little our bosses and supervisors think of us.  Even chickens are being given free range environments.

I'm glad I'm retired and no longer subject to the supervisorial fad-of-the-day.

1

Share this post


Link to post
Share on other sites
5 hours ago, katheliz said:

I worked in an open office environment for years, with up to 14 co-workers.  For our needs, which often crossed, it was very good for collaboration and for collegiality. Ultimately we were put into cubicles.  It was like being caged, though we weren't enclosed.  
Booths?  To me, that shows how little our bosses and supervisors think of us.  Even chickens are being given free range environments.

I'm glad I'm retired and no longer subject to the supervisorial fad-of-the-day.

 

We work in an open space, big room, 12 employees, and mostly we talk work related stuff via Skype.  Why? partially because people do not want to walk, but as well because it is easier to share your desktop and show something on your computer and then the other person talking over and showing something else in his, instead of everyone walking around to different places.  I found it weird at the beginning and just walked to the person always that it was one-to-one, but nowadays I've got used to it.

2

Share this post


Link to post
Share on other sites
8 hours ago, UpToWick said:

 

s. I'm not saying that it's a bad thing to improve yourself, but the way it's often presented is that...you're never good enough. Imagine what disaster this does to the subconscious of a person...

...

 

 

I guess it depends on how it is presented.  I think if you work in IT you need to continuously be learning otherwise you get left behind.  Both as a company and an individual.

 

 

8 hours ago, UpToWick said:

 

...

I've seen teams in different companies that had the following behavior: If a story was not completed during a Sprint (something totally normal and natural...there can be many valid reasons why this happens), they would close the story (so that "officially" they had completed it, and it looked good on the board), and create a new one in the next Sprint, which was basically a continuation of the previous one.

Another behavior that I've seen was rushing to code reviewing a few hours before the Sprint ends...colleagues begging to have the CRs approved, not matter if the code was of good quality or not. Because..."it doesn't look good if I don't finish the story".
...

 

 

IMHO this is not a problem with "Agile".  This is a company cultural problem.  Any tool or methodology is only good if you use it correctly.  If this sort of behaviour is common then they are just kidding themselves that everything is fine and they actually have fundamental problems.

 

There are too many examples in industry today where everything must been seen to be "on time", "resolved" etc. so they basically resort to ticking boxes and just hiding the problems.

 

Example:  Last week I reported an issue to our support team for performance slowdown on my laptop.  The Disk (NVME SSD!) was running > 95% with CPU > 50% for long periods of time, basically bringing my device to a crawl and at times making it unusable.  I highlighted the Apps causing the problems.

 

The support team told me to "uninstall programs" (not related to those causing the problems which I can't uninstall), clear temp files and then closed the ticket!  If the problem resolved?  No!  Has there suggested resolved the problem?  No!  But they want to close the ticket ASAP because they are an external company and are judged by the number of tickets open and how fast they close them.

If you report that the problem is not solved they tell you to "open a new ticket", because this is better for them then reopening the old one.

 

All of these issues are hiding the problem.  But our management think they are doing a good job because tickets are closed quickly and never open for long!

 

 

 

3

Share this post


Link to post
Share on other sites

I’d be fine with 12-15 people in a room, to be honest I wouldn’t call that open plan, rather a team room. Startups these days have open plan offices with 50+ people in a room, often more if the space allows, and it is incredibly stressful.

2

Share this post


Link to post
Share on other sites
1 hour ago, dj_jay_smith said:

 

 

I guess it depends on how it is presented.  I think if you work in IT you need to continuously be learning otherwise you get left behind.  Both as a company and an individual.

 

 

 

 

IMHO this is not a problem with "Agile".  This is a company cultural problem.  Any tool or methodology is only good if you use it correctly.  If this sort of behaviour is common then they are just kidding themselves that everything is fine and they actually have fundamental problems.

 

There are too many examples in industry today where everything must been seen to be "on time", "resolved" etc. so they basically resort to ticking boxes and just hiding the problems.

 

Example:  Last week I reported an issue to our support team for performance slowdown on my laptop.  The Disk (NVME SSD!) was running > 95% with CPU > 50% for long periods of time, basically bringing my device to a crawl and at times making it unusable.  I highlighted the Apps causing the problems.

 

The support team told me to "uninstall programs" (not related to those causing the problems which I can't uninstall), clear temp files and then closed the ticket!  If the problem resolved?  No!  Has there suggested resolved the problem?  No!  But they want to close the ticket ASAP because they are an external company and are judged by the number of tickets open and how fast they close them.

If you report that the problem is not solved they tell you to "open a new ticket", because this is better for them then reopening the old one.

 

All of these issues are hiding the problem.  But our management think they are doing a good job because tickets are closed quickly and never open for long!

 

 

 

 

Very good points.   Now if you go some steps ups in the Agile ladder you will find the "Traffic lights" which every project has in order to provide a "top management" global status of all the company projets.  (For non Agile people, green means the project is running smoothly, yellow there are some problems, red everything is crap).    But then they made the job of the project manager to keep those traffic lights in green.   Of course the project manager will do the impossible to keep that crap in green, whatever it takes.   If the traffic light is not in green then the project manager is not doing his job.   So at the end you have a bunch of projects where everything is crap but all the traffic lights are in green.   People working on those projects complain about the usual suspects, not enough people, not enough training, mediocre specifications, using the wrong tools, etc, etc.   But the top management doesn't react because everything is in green.   Why would the top management implement changers that mean money when everything seems to be working correctly?

 

I am not really a big fan of Agile.  I get your point that it is a tool and you can use a tool for good or for bad, I normally agree with that.   But sometimes the tool is designed to make you shoot yourself on your foot.

1

Share this post


Link to post
Share on other sites
36 minutes ago, Krieg said:

I am not really a big fan of Agile.  I get your point that it is a tool and you can use a tool for good or for bad, I normally agree with that.   But sometimes the tool is designed to make you shoot yourself on your foot.

 

similar to c, it gives you enough rope to hang yourself with it :)

 

I have never seen such high levels of technical debt as I've encountered on agile projects, presumably for the reasons already outlined here.  Oh sure devs ask for refactoring sprints to clean things up or try to introduce tasks to correct especially dangerous areas, but management sees no need as it "works" now, the changes won't be visible to the customer, so clearly there is no need to change anything.  hacks and spaghetti code abound, which quickly leads to a fairly intractable, non-maintainable code base where the only fixes possible involve more hacks and spaghetti code. ad nauseum.  I run the other way from agile projects now as it's just too maddening.

 

another problem with most agile implementations is that no one is "responsible" for anything in particular, and people lose the chance to specialize in areas they either love or are particularly great at doing.  This runs afoul in two directions:  first, you can end up with tasks that no one wants to touch, so it's like a game of hot potato wherein everyone tries to avoid taking it on, and second, the perception (or reality) that people who have no clue what they're doing are prone to meddling with code written by people who do really know what they're doing.  Whether that is objectively true or not doesn't even matter, as the same code will be attacked back and forth by the same two people repeatedly as they essentially fight over the impl.  Neither person has a "right" to the final say as hey, we're all the same!  I've seen so many bizarre, totally unnecessary conflicts that spin out of this alone...ugh.  it just puts knots in my stomach.  bottom line is there can be some advantage to forcing everyone to work on everything, but you know the silly saying,  "jack of all trades, master of none"?  yeah, well it's kinda actually true.  and people who are especially knowledgeable in a given area can end up really dejected as we all like to do things we're good at, right?  well sorry, with agile you can't.  worse, it's "better" if you don't, or some nonsense along those lines.

 

I would much rather work in a massive open office than ever be stuck in a cube again.  <shudder>  with cubes you have all the noise (perhaps more so as people tend to be louder when they feel they can't be seen - similar to how people do weird stuff in their cars as they think they are in a safe space) but there is a strong parallel sense of isolation.  It's horrible.

 

regarding "pressure" to improve...I dunno.  In american companies most devs EXPECT to have the company support them in expanding their skills, and I for one never felt pressured by management to "be better" in a random way, just for the sake of it.  Yes of course if you're not doing a good job with your immediate tasks you need to improve, but most often that's accomplished via mentoring and/or help from your colleagues who already know the drill, whatever that is.  This is very kind and actually productive, and unless you're really flailing and not responding to help, there is no pressure but simply support.  

 

what Managers in Germany do with this concept is another story.  I am going to bite my tongue there as it's just bitching and not productive :)

 

 

1

Share this post


Link to post
Share on other sites
34 minutes ago, Krieg said:

 

Very good points.   Now if you go some steps ups in the Agile ladder you will find the "Traffic lights" which every project has in order to provide a "top management" global status of all the company projets.  (For non Agile people, green means the project is running smoothly, yellow there are some problems, red everything is crap).    But then they made the job of the project manager to keep those traffic lights in green.   Of course the project manager will do the impossible to keep that crap in green, whatever it takes.   If the traffic light is not in green then the project manager is not doing his job.   So at the end you have a bunch of projects where everything is crap but all the traffic lights are in green.   People working on those projects complain about the usual suspects, not enough people, not enough training, mediocre specifications, using the wrong tools, etc, etc.   But the top management doesn't react because everything is in green.   Why would the top management implement changers that mean money when everything seems to be working correctly?

 

I am not really a big fan of Agile.  I get your point that it is a tool and you can use a tool for good or for bad, I normally agree with that.   But sometimes the tool is designed to make you shoot yourself on your foot.

 

I think that part of the problem is that some companies just implement something because it is new, trendy, popular, and works for some.  Without looking at if it is right for them or their customers!

 

We have also adjusted a lot internally to work in this way.  But interesting, we still deliver in a waterfall method to our customers.  Because most don't want a new release every few weeks/months.  Our customers have a 5 - 8 year cycle of upgrading the software (major release), each cycle is a major project which costs millions, and they don't want the overhead of testing and upgrading more often.  Many don't even apply minor upgrades very often.  Some never!

 

But, we also have another customer who is very interested in continuous delivery!

 

2

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!


Register a new account

Sign in

Already have an account? Sign in here.


Sign In Now