SE - Software as a profession

Question

I am currently working as a trainee programmer in a software farm. I am somewhat frustrated and considering abandoning this profession.

I don't agree with the most of the answers of this post.

Can anyone answer the following questions?

1. Is pressure inherent to Software Programming?
2. Is it mandatory for a programmer to grasp the total business process (like the System Analyst) relating to the software he is working with?
3. Is maintenance-coding a part and parcel of this profession?
4. How can I explore new technologies while being involved understanding Business Processes (Coz these two are separate in nature)?
5. and how can I understand what previous programmer coded?

I like coding more than my life. So I came to this profession. But management is pressuring me to understand the range of Business Processes available at their disposal. They also say that I can't exist in this industry only as a coder. Also my own style in coding is hugely discouraged. Also they assigned me 4 projects at a time for maintenance coding.

Answer 1

1. Absolutely. To think otherwise is the definition of naivete. You'll be expected to deliver things on impossible deadlines and without users who know what they really want. Software development is building a product. Usually that product's been promised to somebody else by a certain date. This will absolutely fall completely on you. That's why it's remarkably important to be able to get stuff done.
2. Eventually, yes. S/he doesn't have to know it going into it, but obviously has to be able to learn and understand it. Most business processes are easy to understand, though, so don't fret.
3. See #1. Maintaining code is just as important as writing new code. If you don't maintain it, you'll have very unhappy users and, eventually, a slew of lost customers.
4. Understanding business processes doesn't take up too much time, and I read blogs and news every morning before going to work to keep up with whatever's new. I also do random little coding things in my spare time to experiment. It's really just about time management, and making sure that you aren't forgetting other things that matter, like your family.
5. By reading the code, and studying it until you grok it. Hopefully it's documented, but usually it's not. Also, don't be afraid to ask questions. If you are, you'll never get any answers.

Answer 2

1. Yes, As much as it is to any situation where someone is giving you money to solve problems.
2. No.
3. Yes.
4. Time management.
5. With a debugger and strong cup of coffee.

Answer 3

(1) Is pressure inherent to Software Programming? yes

(2) Is it mandatory for a programmer to grasp the total business process (like the System Analyst) relating to the software he is working with? If he wants to be truly successful then yes. If you only wish to get buy programming what someone tells you too (heads down in a corner somewhere)...then no. But you will never drive the train if you don't know as much as possible.

(3) Is maintenance-coding a part and parcel of this profession? NO...I move around a lot and generally only take on green field applications...something new from the ground up

(4) How can I explore new technologies while being involved understanding Business Processes (Coz these two are separate in nature)? I always look at a new task and try to determine what new technology is best to help me solve the given solution. There is almost always a way to work in new technologies. Unless you work in a bank or something similar...aviation, etc

(5) and how can I understand what previous programmer coded ??????? that part takes time. Seeing someone else's style and learning to live with it, understand it, what to expect from it...and whether or not it is worth the time to rewrite it to make it better

Answer 4

1. Yes. This is a competitive industry and the pressure to succeed, not to mention to beat the snot out of your rivals, is huge.

2. No, but it helps. Just as it helps a marketing person to understand some technology. To borrow a buzzword from the dark side, it's all about the synergies.

3. Of course. Successful software is used, which means people want u-p-g-r-a-y-e-d-d-es. And bugfixes. And compatibility with new hardware. And on, and on...

4. This is where loving your job comes in. If you don't have the inclination to learn on your own time, you won't do well.

5. Ask him or her. If the programmer's no longer around, ask someone with more experience than you. Failing that, step through with a debugger.

Answer 5

(1) Is pressure inherent to Software Programming?

For the most part, yes. The degree of pressure will vary based on what you're doing, but by and large if you've been hired, it's because someone wants something; and very few pay-check-signers like the answer 'when its done'.

(2) Is it mandatory for a programmer to grasp the total business process (like the System Analyst) relating to the software he is working with?

Neccessary? no. Beneficial? yes. If you understand what you are writing you are more valuable, as you can find errors in specs from business experts; along with being better able to find bugs in the business logic you are writing.

(3) Is maintenance-coding a part and parcel of this profession?

Barring a very small set of development, yes. When you own a piece of code, you are an expert on it. A change needed, a bug found? You become the person best able to implement the change. In a more general statement, software is very rarely released complete, bug free, and perfect according to all customers.

(4) How can I explore new technologies while being involved understanding Business Processes (Coz these two are separate in nature)?

Find a way to integrate them, or learn off the clock. Generally, if you're working solo on a prototype, or proof of concept, you can play with new tech; though that likely varied by organization.

(5) and how can I understand what previous programmer coded ???????

Practice, ibuprofen, luck. Amounts of each are dependent on who the previous coder was. Remember this while writing your own code.

Answer 6

My answers (every person's answers are likely to be slightly different):

1) Pressure comes from poor project management. Unfortunately, poor project management is endemic in the industry. Not only is that annoying as a programmer, but it means that most project managers have never seen a successful project manager. Mandatory "crunch time" represents a failure of management. Always. At my former employer, they just mandated that each employee shall work 50 hour weeks for 17 of the next 20 weeks. Without additional compensation. That's just a failure of management, plain and simple. They're making people do this so that upper executives can receive a bonus based on a ship date. The end result is that they will lose their better people and end up with most of their poorer people. If you're working at a company that sucks, brush up your resume, learn a new programming skill and switch companies.

2) Mandatory? No. But it helps to have some common ground between yourself and the customer. How are you expected to make something the customer cares about when you can't even talk to the customer about what they want done? Domain knowledge helps a lot, but its not mandatory that you understand 100% of their domain. That's their expertise. Your expertise is computer programming, which the customer doesn't know. The best way to keep these two in balance is to talk to the customer frequently. Classic "get all requirements up front so we don't have to talk to the customer anymore" is a path strewn with the bodies of failed projects. Don't be afraid to talk to the customer.

3) Yes. Sorry, its just a fact of life. You will spend most of your time extending/fixing an existing code base, not writing new code from scratch. Writing mostly new code from scratch only happens in school because they don't teach you anything about reuse or maintenance.

4) Devote some time to each? Its not a zero-sum game, I don't understand the tension in this question.

5) Over time you'll develop more skills in understanding other people's code. If they wrote a unit test suite, treat that as executable documentation. (In my experience, you'll be lucky if such a unit test suite exists.) Otherwise, you can write your own unit tests against Other People's Code as a way to validate your own ideas about how that code is supposed to work. Unfortunately because people who write code without unit tests tend to write highly coupled code, that's also difficult most of the time. When we purchase other people's code that is ugly, I just start refactoring on it. Rename. Move Method. Extract Method. Extract Class. Over time it gets better. I will add unit tests to it if its particularly nasty and particularly important.

But basically it comes down to one thing. If you don't like writing code, you shouldn't have a job writing code. I've been writing code for 30 years and I still love writing code. I write code very differently now than I did 30 years ago when I was 13, though :-).

Answer 7

1) Yes, of course, but the amount and how it's handled varies. Some places are simply sweatshops, and that has nothing to do with software.

2) It depends on the programming. Sometimes all you really need to focus on is a self-contained, abstract problem, such as the right algorithm to keep things sorted. But, realistically, the more you see the big picture, the more able you are to make the right decisions.

3) The moment you hit Enter, you've become a maintenance programmer. Legacy is just a dirty word for the code you wrote a moment ago. That's why code quality is defined as much by maintainabiity as its current execution characteristics.

4) They're different issues and largely unrelated. Sometimes understanding the business drives you into exploring new techniques that work well in the context. Mostly, they have nothing to do with each other.

5) If they did their job, it will be easy to understand what they did.

Answer 8

Hi,

I have sympathy for you. If you don't think you can cope with the pressure abandon early than late, it gets worse as you grow higher.

Answering your questions

1. Yes it is. Primarily because software isn't worth a dime until the last line is written. And the investor is usually paying you a lot of money to develop. So he's depending on 'you' to make things work. All delays cost a lot.

2. Since the programmer will have to make sure the system works in totality, I think it is important to understand what the expectations are from the system.

3. Of course! Without maintenance an application cannot be used for long. Requirements change, so do system specifications. You have to maintain your code. You created it! You can't let it be an orphan.

4. By working very hard. By stretching your day. By cutting party-time. By taking very quick showers and keeping a beard :) (or use an electric razor).

5. By watching very carefully, stepping through the code and dissecting every single line with intentness and purpose.

Answer 9

Well, I chose this profession a long time ago (what little hair I have left is quite grey.) Here are my answers:

1) Pressure is a big part of development because code is fragile: one extra paren in my Pascal project in school generated 300 errors. But nothing beats the feeling of finishing something cool.

2) You don't have to understand the business process, but how will you know your requirements are adequate (or correct) if you don't.

3) Maintenance is life. If your product is breaking, it means people are still using it.

4) Unfortunately, the availability of new technology depends on your management. I worked for two managers in the same corporation: one provided tools to work with and the other didn't (but he did expect us to work 60 hours a week).

5) Understanding existing code is a knack. I wish there was a secret to share but you have to step your way through it.

Answer 10

(1) Is pressure inherent to Software Programming?

Not exactly. PressuredJob extends SoftwareProgramming extends Working extends Everything

(2) Is it mandatory for a programmer to grasp the total business process (like the System Analyst) relating to the software he is working with?

Yes, domain knowledge is the most important thing in software programming. Have domain knowledge will help you. You can reference the "No silver bullet" and "domain-driven design".

(3) Is maintenance-coding a part and parcel of this profession?

Yes, do you want write code and not maintain it.

(4) How can I explore new technologies while being involved understanding Business Processes (Coz these two are separate in nature)?

It's not conflict. The more you understand domain the deeper you understand the new tech. "new tech" for the domain, domain because of "new tech".

(5) and how can I understand what previous programmer coded ???????

So ... think another programmer who's job is maintain your code.

Answer 11

Can anyone answer the following questions?

My Background I started programming when I was 13. I'm now 34. I've been programming professionally for about 15 years, but even in my spare time I just write different software. I consider it fun and challenging. I know most popular languages and can pick up a new one pretty quickly. So take that in mind when considering my answers.

(1) Is pressure inherent to Software Programming?

Pressure is not inherent to programming as a practice, but in general it is part of programming when that is your main business. In scientific circles your top priority may be getting the exact right provable answer. In business there are time to market, hourly wages and competition costs that puts pressure on management to get the most out of their programmers as they can.

Having worked in the trenches, done management and owned my own business I will simply say you are not thinking outside your own priorities much. You should know and understand why there is pressure and exactly what it is. Maybe your work culture is structured such that you're not in a position to understand but pressure is very real for way to many reasons to list here.

The biggest cause of pressure in regards to programming in my experience is poor communication coupled with poor time estimation skills. This seems to be the universal problem in the realm of programming and coupled together makes life a living hell if you do not do your best to reign in these two monsters.

(2) Is it mandatory for a programmer to grasp the total business process (like the System Analyst) relating to the software he is working with?

Not at all. You can be a cog in the machine as long as you understand what it is you're doing.

The flip side of this is that you'll only create things based on your explicit directions or understanding of the task. If you don't know WHY a widget needs to perform some process then your software to accomplish the task will only have a good chance of being technically functional but from a user perspective will be somewhere between cumbersome to useless.

(3) Is maintenance-coding a part and parcel of this profession?

80 to 90% of what you do will be maintenance coding. You will never get it right the first time. You will always have bugs. There will always be changes. This is the life of a programmer.

(4) How can I explore new technologies while being involved understanding Business Processes (Coz these two are separate in nature)?

Business programming doesn't care about technologies, except as needed to accomplish the task at hand. You'll almost never need to build you're own low level balanced binary tree algorithms or anything else computer science like for business. This is not entirely true, but based on the type of place you mention you're at right now you are not being paid to think. You're being paid to type out a database user interface every day for the foreseeable future.

If you settle into it and produce consistently you can do well for yourself. Hell you don't even need to be that GOOD if you're consistent and I can estimate how much work I can get out of you with some amount of accuracy.

(5) and how can I understand what previous programmer coded ???????

--> Experience. <--

Writing software is MUCH easier then reading it.

If you can't read it then you don't really know what you're doing. You're probably smarter then the average person, but still not a master of your profession. It takes a long time and lots of bug fixing before you'll be able to figure out what the previous person's code is actually doing and it will take you even longer to figure out WHY they did it that way.

This goes back to poor communication.

Programming is simply writing down instructions to solve a particular task. If you can't figure out what the previous person wrote you don't have much chance of making it do something different. The previous person may not have expressed their answer correctly and you are also tell us in this question that you're not good at reading code either.

They are called programming "languages" for a reason.

It's late for me, but that's my answer / advice. In closing if you really like programming for discovering and solving problems you may want to go into another profession. You won't be burnt so burnt out by your day job that your passion for programming becomes the pressure of a thankless job. Your can use your skills at writing software to solve problems no one else has thought of before. You'll find your skills will be much more appreciated surrounded by others who can't express themselves as well on the computer.

Answer 12

(1) Is pressure inherent to Software Programming? -- No, but it is common in many organizations. It isn't inherent at all, though.

(2) Is it mandatory for a programmer to grasp the total business process (like the System Analyst) relating to the software he is working with? -- No, you could be on a team where the Team lead defines small pieces and specs and you just implement that. Frankly, I would find this a little boring -- I'd rather understand what kind of problem I'm trying to solve.

(3) Is maintenance-coding a part and parcel of this profession? -- Not necessarily. You can be a "hero" who gets pulled into a new startup to get things going, and moves onto another job leaving your code (and mistakes) behind for others to maintain. If you spend any time at any job, you will have ot at least maintain your own code. I think it makes you a better programmer -- most of the cost of programming is spent on maintenance, and if you never maintain any code, how can you understand how to design for maintainability?

(4) How can I explore new technologies while being involved understanding Business Processes (Coz these two are separate in nature)? -- It's called multi-tasking -- you can do more than 1 single task no?

(5) and how can I understand what previous programmer coded ??????? programming -- It will come to you with time and experience, Grasshopper :)

Answer 13

(1) Is pressure inherent to Software Programming?

No.

(2) Is it mandatory for a programmer to grasp the total business process (like the System Analyst) relating to the software he is working with?

No.

(3) Is maintenance-coding a part and parcel of this profession?

Yes.

(4) How can I explore new technologies while being involved understanding Business Processes (Coz these two are separate in nature)?

Divide your time.

(5) and how can I understand what previous programmer coded ???????

Several things will help you to do so:

• The fact that your company honors Coding Standards which enforce things like the KISS (Keep It Simple Stupid) principle and other well accepted Object Oriented software practices.
• The fact that all parts of the software process have deliverables, so you won't have only code - you'll have also requirements, specifications and design documents.
• Books like Working Effectively With Legacy Code.
• The fact that you are smart and get things done.
• The possibility to ask other members of the team for help.

Answer 14

1. I'd be tempted to ask what kind of pressure you mean. Most people want something as fast, cheap and good as possible which tends to create some pressure but some methodologies try to minimize this issue.

2. No, however it can be useful to know as much as possible to implement various optimizations that could mean a great deal.

3. No, there are some situations where you wouldn't have this. Systems Integrators may have some maintainence as part of their contracts with clients but this depends on where you find the work you like.

4. My guess would be that they aren't exclusive if you have the proper perspective. If you are going to replace system X then you may need to look at what solutions are out there and some may involve new technologies which is a way to get exposure to that. Perhaps I have a different take on how Business Process knowledge is to be used.

5. You can't, pure and simple.