Jump to content

Leaderboard

Popular Content

Showing content with the highest reputation on 02/06/2015 in all areas

  1. The big one for me is flexibility. With two young children, having the ability to work part time, stay home for snow days, leave early for school events is huge. Simply being able to be flexible with my hours without being penalized is a big part of my job satisfaction. The next biggest thing for me is project diversity - I like being challenged.
    2 points
  2. First off I think you might get limited responses from people on this, but I might be wrong. Many people who work with LabVIEW daily and are on these forums, know that this is a public place, and anything they say may come back to their employer. That being said I don't mind commenting I have nothing to hide but others may not be so open. In my mind, increased salary and other monetary benefits help you feel satisfied only until a certain point. After an employee is paid enough to not have to worry about money, they can get a decent savings, and pay off debt, and beyond that an increase in pay is nice but I think factors less into satisfaction. For me satisfaction has to do with accomplishing things. I was given a task that I could then do. Maybe it is a task I have had before but now I do it faster or better. Or maybe it is a new challenge and I was able to get it done for the first time. But after I've completed my task, some recognition is nice. I'm not saying I need a pat on the back after every work day, but having those around me appreciate my work, and understand my value, brings satisfaction. Especially when it comes from those I work with often, and those above me, like a boss. I could also mention other things that I like about a job that don't really add to satisfaction, but could detract from it if it were missing. Like having an open an inviting team that helps each other grow is important. Having that doesn't make me feel more satisfied, but not having that could take away from my satisfaction. It sounds like an interesting book and FYI it is $17 on kindle.
    2 points
  3. Update... I've been working with NI tech support to try and resolve the error. I trimmed my code back to a splash screen before the issue went away. I've waved the dead chicken and NI R&D has been looking at what's going on. In between emails from NI, I started rebuilding the code from the ground up with a lot of copy paste and some changes with the benefit of hindsight. I've built back up the application to nearly the same functionality and have not had the same issue when compiling. While I have made some changes, I've had an issue with a different piece of code that appears to be corruption in a class, so I'm highly suspicious I have the same issue with this code. Lessons (re)learned: 1. Compile often 2. SCC 3. SCC 4. SCC
    1 point
  4. I have to strongly disagree the timing of changes against actual release date is a very key. Also as you get nearer the release date the types of changes allowed into the release should change. In the early part of the release cycle the release manager should be locked away in a cage with a cover over it; the only gatekeeping should be your standard SCC control process, which should include things like nightly builds and automatic regression testing. At this time new "agreed" functionality is added and bugs fixes applied and yes it can and in some cases should be a free for all. As the time to release gets nearer the process changes, there comes a point that new functionality should not longer be allowed, functionality added that may not really work as expected or at all, may need to be pulled from the release, this sort of decision is hard and based on a mixture of risk against what the customer has been promised. The release manager at this point is out of his cage and working up to full paranoid mode. By now your regression testing suite should be extensive, however you will also need to be doing manual testing and stressing of system as regression testing can never cover the full functionality of a system. In the final run up to the release no change other than bug fixes should be allowed and even then the developer should be made to walk over blazing hot coals first to see that they really are serious in their commitment to them. In my past I have worked as a release manger on several high value financial systems (oil trading and Europe bond markets) The reality is that even following due diligence and good regression test does not mean you have not introduced an unexpected problem. On the systems I was working on a full test cycle to run through all the test case was in the order of a week. As a release manger, I have had many experiences of developers saying "I have found a bug and this is the fix, do not worry nothing else will be affected" followed a week later by "ahh I did not see that coming". As a developer I have had experiences where I have found a bug and thought of simple small fix only to be caught out by and unexpected side effect or impact. Programming is not easy especially in modern large systems and even the very best developer can and at time will get it wrong. So lets hear it for release mangers they are human too.
    1 point
  5. That's what risk assessments are for. Fire the manager and distribute a spreadsheet.
    1 point
  6. There's an interesting RSA Animate by Dave Coplin. I'm not sure I agree with everything he says, but there are many salient points he raises as to why many feel dissatisfied with work.in the current age. Personally. I think the criteria for job satisfaction is a moving target and changes dependent on age and circumstance. In the beginning most people are primarily concerned with financial and educational reward (the latter mainly to enhance the former). Then family comes along and time at home and flexibility becomes more desirable and work is a means to an end rather than a personal journey. If you are middle class and in a specific field then once you have attained a certain competence in your field; exercising the limits of your knowledge and choosing the interesting tasks seems to be a primary consideration. Towards the twilight of a career, guarding that pension pot seems to be the primary driver. A rare few have a hobby that makes enough money to support a family with oodles left over for a car, house and yacht. Most are not in that category, but those that are tend to be extremely happy both in and out of work. There is a saying, where I come from. Job satisfaction is 20% of your wages. On the surface it seems rather trite except if you re-interpret wages to mean benefits. However, it goes some way to explaining why many are willing to do open source for pennies if not for free as long as a minimal survivable income is catered for.
    1 point
×
×
  • Create New...

Important Information

By using this site, you agree to our Terms of Use.