* Company X outsources, laying off 1,000 engineers who made an average of $75K/year.
...
* Because it costs Company X more money in taxes, their profits don't soar, as they assumed they would as a result of outsourcing.
The problem here is that is may take at least 6+ months of time between cause (the 1st point above) and effect (the last point) - by then the people making the outsourcing decisions have cashed in their options and moved on! Bad for the company, yes, but rarely bad for the actual people making the decisions.
The difference between the enterprising attitude of countries like the US and those of our hillbilly minister Alston is that they understand that there is damn good money to be made out of porn and games!
While we are at it, let's at least have the decency to get their name right : civilians of "Iraq".
Mind you..... Keep up this talk of "Irak" and Bush will think he is bombing the wrong country and get the Atlas out looking for "this damn Irak place".
Developing "real" systems & job variety.
on
Good Job Experiences?
·
· Score: 3, Interesting
One of the best jobs I've had was working for a small consultancy company (in Melbourne). Because it was such a small company they were very few boundaries of "this is your job... do this and nothing else" and plenty of opportunities existed to get involved in liaising with customers, installing and supporting systems... all the "other" activities that surround just "developing" a system - some people considering them boring activities, but I've had some pure development roles, and the lack of variety in the day to day work does grind you down a bit.
But, from a job satisfaction point of view, what really made this job a rewarding experience was working on real systems where you could see the immediate benefits they provided the customer. A case in point was the airport logistic systems we developed for one of the airlines... it always gave me a buzz to walk into the airport terminal, look up at the flight information screens and know that the system that is putting all that together is one you have worked on.
On the other hand, no matter how much "latest and greatest" technology you are getting your hands dirty with or the amount of TLAs piling up on your resume, if the system/program/application you are working on never actually sees the light of day, the buzz just ain't there.
Ironically I've just resigned from a job at a telco, working on "cutting edge technology" that is becoming less and less likely to see the light of day to go back to work for this previous small company - because for me the payoff is in the variety of experiences on offer and the sense of professional and self-worth that comes from actually seeing somebody make use of your hard work.
I've been writing Client side Java GUI programs for about 3 years now. Some have been small interactive graphing tools, but more recently I've been working on a large Debugging Tool API program. In my experience, it is possible to create Swing applications that are:
Visually pleasing
Fast and Responsive
Scalable
However, I have found to achieve these goals at a high level of quality has taken significant experience and many dead-ends. Java Swing GUI's are NOT for "rapid GUI application" the same way that VB is marketed as for instance. It takes solid knowledge of the Swing API - which in my opinion is a very powerful flexible GUI API, but one which comes with lots of "gotchas" to watch out for.
In my experience I would say that a good Client side Java GUI can be developed, but the following pitfalls need to be avoided:
Avoid GUI Code Generator tools to design your GUI layouts. They lead to highly unmaintainable GUI code but more importantly to less consistent screens (have a read of Building user interfaces for object-oriented systems for more details
Build a decent framework that sits ontop of Swing to automate and standardise the process of view creation. I've found Swing GUI work can be made significantly more productive and easier to maintain if Swing screens are being automatically generated from data objects. For example, I use a Field builder to generate appropraite Swing fields (text box, combo box, check box etc) depending on the Type of the data field (String = text box, Boolean = check box etc). This way the interface remains constant and up to date with any chances to the data model.
Know when to deligate work to a background thread, instead of tying up the AWT Event thread... this is a common mistake in Java GUI's that gives the perception of an unresponsive or frozen application
For large applications, distribute a decent Java Runtime for your application to run on. This is the approach Borland takes with JBuilder. You are distributing a big app, so why not bundle with it a robust JVM that you have tested your app on?
but who do those Library maintainers fix those bugs??? The buck stops somewhere. One day you might be the one writing the library. How do you track down obscure bugs in it?
The type of response I was trying to get out of people with this post is Why do you use printf's???... obviously there is something lacking in modern debuggers that we need to use printfs... now think outside the square and look at it this way... how could a debugger be made better to remove the need for this type of explicit program logging? Could there be a way to accelerate program development and improve quality as a result? These are the sort of responses I was hoping for.
Ok, lots of responses along the lines of "Real Men Don't Debug" to this post, but whilst I'm sure all/. developers write fantastic code with no hard to track down bugs, in my experience you can spend a lot of time tracking down other peoples bugs! - you don't always get to work on nice clean systems from scratch.
Another reason I think it is important to focus on debugging tools is that, despite the name, they are not always used to debug! One of the major uses of a debugger is to understand the dynamic behaviour of a program.
Whilst not so big an issue in the current climate, there was a time not so long ago where companies had a very high turnover of developers and it was very common to start work on a project where the previous developers that did the bulk of the work were no longer employed there. Often UML and design documents were no-existant or well out of date with the actual source code, so the best of figuring out just how the system worked was to load it up into a debugger and see what it did.
Before I get replies pointing out that a good code review will reveal the workings of the program, I'll point out that often the dynamic behaviour of a program (and this where the need for good debuggers comes in) - how it responds to various inputs - can often be hard to assertain in non-trivial systems. All programs are essentially Turing State Machines and if it were always possible to work out how a program would run from it's source code there wouldn't be such a thing as the Halting State Problem would there?
A quick example to finish off this post and perhaps generate some more discussion on debuggers (or perhaps to use a better term, Program Inspectors/Visualisers) - design and code reviews are not everything. A simple example is a Binary Tree used for sorting input data. The UML diagram is very simple, the algorithm straightforward. According to the design and code review it should deliver O(log n) performance to find a given item. But as any student of computer science will point out, if you input an already sorted dataset into a binary tree structure you end up with a list with performance degraded to O(n). It's a trivial example, but it does highlight the need for understanding how programs respond to different inputs at runtime - something that better debugging tools would help with.
So, now imagine you have inherited some monolithic monster of an undocumented system. Nobody knows how it works or was put together. There are two dozen outstanding bug requests that you need to fix..... just what sort of debugging tool would you be praying for at this stage??
I started off my career as a Software Engineer with degrees in both Computer Systems Engineering and Computer Science, but over the years I've feel the best software I develop is through an evolutionary process rather than a rigid design everything first based approach.
Too often after spending weeks nutting out a design document with UML, dozens of use-cases, once you start programming and running initial versions of the software, the design will quickly become invalid and the design will be refactored to work better.
The reason this invariable occurs is that software processes are inheriently complex systems. No matter how well thought out a design, it is impossible for anything but the most trivial of systems to envisage all possible states the program could end up in - this is because software processes are driven by dynamic input that is hard to predict. This is why the best understanding of how a program should work (and how it currently does not meet design requirements) is during the runtime execution of a program where it's dynamic behaviour can be examined.
This is why I feel the higher quality software I have developed is usually the result of software where I start out with a preliminary design - don't try to solve everything up front, just spend an hour or two outlining a high-level approach. I usually break the problem being solved down into a series of simplier problems - program to solve them, profile the dynamic behaviour of the program to see how well it solves the program, then go through an iterative process to improve and extend the program.
This is why writing good software is very different to designing a bridge. You can't iteratively design a bridge - it needs to be well thought out before you order the bill of materials and get a large workforce moving on it. However I feel that trying to fully work out a design of a software process before even trying out a simple version of it to see it's runtime behaviour can often be wasted. The design will rarely handle every possible dynamic situation the program can end up in. An iterative design-program-test process is the more efficient way of designing software.
Slashdot Mirror
* Company X outsources, laying off 1,000 engineers who made an average of $75K/year.
* Because it costs Company X more money in taxes, their profits don't soar, as they assumed they would as a result of outsourcing.
The problem here is that is may take at least 6+ months of time between cause (the 1st point above) and effect (the last point) - by then the people making the outsourcing decisions have cashed in their options and moved on! Bad for the company, yes, but rarely bad for the actual people making the decisions.
The difference between the enterprising attitude of countries like the US and those of our hillbilly minister Alston is that they understand that there is damn good money to be made out of porn and games!
Mind you ..... Keep up this talk of "Irak" and Bush will think he is bombing the wrong country and get the Atlas out looking for "this damn Irak place".
One of the best jobs I've had was working for a small consultancy company (in Melbourne). Because it was such a small company they were very few boundaries of "this is your job... do this and nothing else" and plenty of opportunities existed to get involved in liaising with customers, installing and supporting systems ... all the "other" activities that surround just "developing" a system - some people considering them boring activities, but I've had some pure development roles, and the lack of variety in the day to day work does grind you down a bit.
But, from a job satisfaction point of view, what really made this job a rewarding experience was working on real systems where you could see the immediate benefits they provided the customer. A case in point was the airport logistic systems we developed for one of the airlines ... it always gave me a buzz to walk into the airport terminal, look up at the flight information screens and know that the system that is putting all that together is one you have worked on.
On the other hand, no matter how much "latest and greatest" technology you are getting your hands dirty with or the amount of TLAs piling up on your resume, if the system/program/application you are working on never actually sees the light of day, the buzz just ain't there.
Ironically I've just resigned from a job at a telco, working on "cutting edge technology" that is becoming less and less likely to see the light of day to go back to work for this previous small company - because for me the payoff is in the variety of experiences on offer and the sense of professional and self-worth that comes from actually seeing somebody make use of your hard work.
However, I have found to achieve these goals at a high level of quality has taken significant experience and many dead-ends. Java Swing GUI's are NOT for "rapid GUI application" the same way that VB is marketed as for instance. It takes solid knowledge of the Swing API - which in my opinion is a very powerful flexible GUI API, but one which comes with lots of "gotchas" to watch out for.
In my experience I would say that a good Client side Java GUI can be developed, but the following pitfalls need to be avoided:
- Avoid GUI Code Generator tools to design your GUI layouts. They lead to highly unmaintainable GUI code but more importantly to less consistent screens (have a read of Building user interfaces for object-oriented systems for more details
- Build a decent framework that sits ontop of Swing to automate and standardise the process of view creation. I've found Swing GUI work can be made significantly more productive and easier to maintain if Swing screens are being automatically generated from data objects. For example, I use a Field builder to generate appropraite Swing fields (text box, combo box, check box etc) depending on the Type of the data field (String = text box, Boolean = check box etc). This way the interface remains constant and up to date with any chances to the data model.
- Know when to deligate work to a background thread, instead of tying up the AWT Event thread
... this is a common mistake in Java GUI's that gives the perception of an unresponsive or frozen application
- For large applications, distribute a decent Java Runtime for your application to run on. This is the approach Borland takes with JBuilder. You are distributing a big app, so why not bundle with it a robust JVM that you have tested your app on?
Just my 2c - happy App building.but who do those Library maintainers fix those bugs??? The buck stops somewhere. One day you might be the one writing the library. How do you track down obscure bugs in it?
The type of response I was trying to get out of people with this post is Why do you use printf's??? ... obviously there is something lacking in modern debuggers that we need to use printfs ... now think outside the square and look at it this way ... how could a debugger be made better to remove the need for this type of explicit program logging? Could there be a way to accelerate program development and improve quality as a result? These are the sort of responses I was hoping for.
Ok, lots of responses along the lines of "Real Men Don't Debug" to this post, but whilst I'm sure all /. developers write fantastic code with no hard to track down bugs, in my experience you can spend a lot of time tracking down other peoples bugs! - you don't always get to work on nice clean systems from scratch.
Another reason I think it is important to focus on debugging tools is that, despite the name, they are not always used to debug! One of the major uses of a debugger is to understand the dynamic behaviour of a program.
Whilst not so big an issue in the current climate, there was a time not so long ago where companies had a very high turnover of developers and it was very common to start work on a project where the previous developers that did the bulk of the work were no longer employed there. Often UML and design documents were no-existant or well out of date with the actual source code, so the best of figuring out just how the system worked was to load it up into a debugger and see what it did.
Before I get replies pointing out that a good code review will reveal the workings of the program, I'll point out that often the dynamic behaviour of a program (and this where the need for good debuggers comes in) - how it responds to various inputs - can often be hard to assertain in non-trivial systems. All programs are essentially Turing State Machines and if it were always possible to work out how a program would run from it's source code there wouldn't be such a thing as the Halting State Problem would there?
A quick example to finish off this post and perhaps generate some more discussion on debuggers (or perhaps to use a better term, Program Inspectors/Visualisers) - design and code reviews are not everything. A simple example is a Binary Tree used for sorting input data. The UML diagram is very simple, the algorithm straightforward. According to the design and code review it should deliver O(log n) performance to find a given item. But as any student of computer science will point out, if you input an already sorted dataset into a binary tree structure you end up with a list with performance degraded to O(n). It's a trivial example, but it does highlight the need for understanding how programs respond to different inputs at runtime - something that better debugging tools would help with.
So, now imagine you have inherited some monolithic monster of an undocumented system. Nobody knows how it works or was put together. There are two dozen outstanding bug requests that you need to fix..... just what sort of debugging tool would you be praying for at this stage??
I started off my career as a Software Engineer with degrees in both Computer Systems Engineering and Computer Science, but over the years I've feel the best software I develop is through an evolutionary process rather than a rigid design everything first based approach.
Too often after spending weeks nutting out a design document with UML, dozens of use-cases, once you start programming and running initial versions of the software, the design will quickly become invalid and the design will be refactored to work better.
The reason this invariable occurs is that software processes are inheriently complex systems. No matter how well thought out a design, it is impossible for anything but the most trivial of systems to envisage all possible states the program could end up in - this is because software processes are driven by dynamic input that is hard to predict. This is why the best understanding of how a program should work (and how it currently does not meet design requirements) is during the runtime execution of a program where it's dynamic behaviour can be examined.
This is why I feel the higher quality software I have developed is usually the result of software where I start out with a preliminary design - don't try to solve everything up front, just spend an hour or two outlining a high-level approach. I usually break the problem being solved down into a series of simplier problems - program to solve them, profile the dynamic behaviour of the program to see how well it solves the program, then go through an iterative process to improve and extend the program.
This is why writing good software is very different to designing a bridge. You can't iteratively design a bridge - it needs to be well thought out before you order the bill of materials and get a large workforce moving on it. However I feel that trying to fully work out a design of a software process before even trying out a simple version of it to see it's runtime behaviour can often be wasted. The design will rarely handle every possible dynamic situation the program can end up in. An iterative design-program-test process is the more efficient way of designing software.