Software engineering as career.

[tsavvy]

If i ask a company, will they show me around for me to see how the life of a software engineer is in the office?

I also would like to get "tips" about what to expect when I start working and just more cool stuff - because i love programming and making new stuff and learning new things. (Web development is awesome, but I think I would be better at software engineering/development and like it more)

My aim is to one day work for a software engineering/developing company when I'm finished studying so I just want to take a look at what it's like being a full time software engineer...

 

[adsl2]

Most companies will have no problem showing you around and will maybe even let you shadow someone for a day or two.

 

[tsavvy]

OK thanks..

I also just want to know if im right-ish :

If I know Java/JEE and C#.net at a young age it would help me a lot one day in the future - because that is whats mostly used for software engineering in companies?

 

[Hamster]

It'll help you at the start. After that, what helps is you being able to do (or willing and able to learn) whatever is needed from you.

 

[tsavvy]

Thanks!

I reaaaalllyyy want to become a software engineer

 

[Hamster]

As for the "a day in the life" experience you are looking for: that'll differ depending on the company and team.

Best advise I can give is to go work for a software house and not an IT department.

 

[freddster]

As for the "a day in the life" experience you are looking for: that'll differ depending on the company and team.

Best advise I can give is to go work for a software house and not an IT department.

Why?

 

[Hamster]

Why?

Because then the focus of the company is software (I'm not talking if small four man startups, dev companies with 100+ devs).

With IT departments come a lot of bs, red tape and an epic battle of middle management egos fighting for dominion

Not always the case, but mostly. Banks are a great example of this.

 

[freddster]

Because then the focus of the company is software (I'm not talking if small four man startups, dev companies with 100+ devs).

With IT departments come a lot of bs, red tape and an epic battle of middle management egos fighting for dominion

Not always the case, but mostly. Banks are a great example of this.

Agreed. Never go for the very big corps, they suck. Politics , oh dear God.
But dev houses. Worked for a couple , that sucked. If you want to be a little meat processor, stuff in , stuff out. You do the dev shop. You want to be part of business, you go corporate. But be prepared to take the politics or just ignore it. There are lots of arseholes in that game.

 

[rorz0r]

+1 for comments about dev shops vs IT depts/banks. I'm pretty happy at a "startup" (been thing for 2 years and has 18 employees) but while I'm in an IT dept of sorts the companies primary product is really their platform and there aren't really any other "departments" that consist of more than one person yet.

 

[cguy]

OP, what are you studying?

On the IT dept. vs SW shop discussion:
- It always makes sense to try work in a profit center, rather than a cost center.
- If the company's primary business is not SW, there will eventually be an interface between the SW people and the internal "customers", which will likely be quite trying (imagine people who have no idea how long a piece of software will take to develop(well, less idea than usual), setting targets and deadlines for you).
- Even if you are in a SW house, it is better to work on some software product that forms the core business rather than doing work for external customers - this means that you don't have to deal with unreasonable external customers, can work on a project from inception to deployment, and be credited with its success, etc.

That said, these aren't hard and fast rules - some non-SW firms recognize that SW is the backbone of their companies an treat it as such.

 

[zippy]

OP, what are you studying?

On the IT dept. vs SW shop discussion:
- It always makes sense to try work in a profit center, rather than a cost center.
- If the company's primary business is not SW, there will eventually be an interface between the SW people and the internal "customers", which will likely be quite trying (imagine people who have no idea how long a piece of software will take to develop(well, less idea than usual), setting targets and deadlines for you).
- Even if you are in a SW house, it is better to work on some software product that forms the core business rather than doing work for external customers - this means that you don't have to deal with unreasonable external customers, can work on a project from inception to deployment, and be credited with its success, etc.

That said, these aren't hard and fast rules - some non-SW firms recognize that SW is the backbone of their companies an treat it as such.

I come from an accounting background and have found that this makes working in an IT dept better for me. I trained as auditor and therefore I can get to grips with business processes and understand business specs in business jargon. Being able to relate and respond in "business-speak" means that they tend to listen to me when I tell what they want is impossible in the time frames they expect given the resources. I'm not saying I am uniquely qualified, but it has helped me.

I have also worked in a dev shop and I don't think there is much of difference when it comes to office politics. You get idiots in both.

They key is to find an organisation where you can fit into the team. That can be a dev shop, a small IT dept or a big corporates IT dept.

The simple fact is someone is always going to want something as fast and as cheaply as possible. It's on the developer to learn how to manage expectations. If you respond intelligently without hysterics, they usually accept your point of view because they need you. But make sure that when commit you deliver or at least give adequate warning if there problems. The worse thing any developer can do is not say anything until the very last minute if they aren't going to meet the agreed deadline.

 

[krycor]

I think the worse thing that I see happening these days is that dev shops take on risk they can't manage and expect their developers to save them where standard dev practices do not allow the project to start.

The sad thing is, most times, the dev shop and customer know they doing it wrong

 

[freddster]

I think the worse thing that I see happening these days is that dev shops take on risk they can't manage and expect their developers to save them where standard dev practices do not allow the project to start.

The sad thing is, most times, the dev shop and customer know they doing it wrong

Over committing?

 

[>Reaper<]

Because then the focus of the company is software (I'm not talking if small four man startups, dev companies with 100+ devs).

With IT departments come a lot of bs, red tape and an epic battle of middle management egos fighting for dominion

Not always the case, but mostly. Banks are a great example of this.

This!

 

[me_]

Software engineering as a term is used in many different contexts and can mean different things. In many European countries, the difference between a software developer and an engineer is the degree you have - a software engineer would have some form of engineering degree behind them and a software developer would not.

Locally there is no requirement for this and many companies (and people) use the terms interchangeably. I see them differently though - A developer designs and build systems with limited knowledge of the underlying environment. A software engineer is an expert in the underlying platform (OS, DBMS, etc) with a very good understanding of the hardware. Engineering is often about finding ways to do things better and looking at new products / features. It has less to do with doing daily development and needs a much wider range of skills.

 

[me_]

I think the best place to gain the necessary skills is a small corporate environment that isn't too heavily silo'd. Large corporates believe in specialisation and will rarely allow you to cross skill and dev shops are usually too focused on dev. Engineering skills can be better learnt from an ops / devops environment where you get to do some development, but also get experience with packaged applications and seeing how various vendors have solved various problems. There is also a lot to be gained by trying to fix / optimise packaged products within an environment.