next »

[Destral]

I fixed a bug that had been bugging me since Saturday today, plus I've been learning a lot working on my project. Maybe I'm not quite a programmer yet, but I'm a happy GML scripter. That counts, right? 

[bateleur]

That counts, right?

That definitely counts. I'd argue programming isn't even about code. In fact code holds programmers back initially because they worry about stuff like syntax instead of focussing on what they're trying to do.

Last week I was walking my daughter (who is 9) through the Unity code I was writing. She expressed the view that my function was "really confusing", so I asked her how she'd do the same thing in Scratch and she had this whoooooah moment when she realised it was basically exactly the same.

And before that was the jump from Little Big Planet to Scratch. But it's all programming.

[st33d]

Ah.

It's time again to roll out the The Story of Mel.

[Average Software]

I'd argue programming isn't even about code. In fact code holds programmers back initially because they worry about stuff like syntax instead of focussing on what they're trying to do.

Programming is all about code.  Focusing on what you're trying to do is software engineering.

[_Tommo_]

Programming is all about code.  Focusing on what you're trying to do is software engineering.

Software Engineering is all about drawing UML and talking shit and buying expensive bloated tech to look like you know what you're doing and get funded once again.

Programming instead is all about solving problems with algorithms, and it's a way of viewing things that can be applied to a lot of situations... so I'm with bateleur.

[Average Software]

Software Engineering is all about drawing UML and talking shit and buying expensive bloated tech to look like you know what you're doing and get funded once again.

Oh lord yes.  UML was invented just for the 'consultants'

I've rarely seen something so freaking useless.

I like to quote Dark Helmet in Spaceballs whenever I see UML.

"Stop preparing to do everything and just do it!"

[ThemsAllTook]

Software Engineering is all about drawing UML and talking shit and buying expensive bloated tech to look like you know what you're doing and get funded once again.

Programming instead is all about solving problems with algorithms, and it's a way of viewing things that can be applied to a lot of situations... so I'm with bateleur.

Interesting perspective. I think of software engineering in a completely different way - essentially as a form of more strictly-disciplined programming which may take longer but produces better results. Suppose I want to write a piece of code that's central to an application I'm developing. Depending on whether I'm in "engineer mode" or not, here are two different ways it could go:

1. I jump in and hammer out the code right away. It's done in a day, and is 800 lines long. There are a few bugs initially, and I may have to go back and refactor it later because I didn't put a whole lot of thought into making the API clean or ensuring that it's easily testable, but in a lot of cases it'll just work.

2. I take some time to plan, design every aspect of the API with great care, and implement the whole thing using TDD with full unit test coverage. It takes a week to finish, and is 300 lines long with 700 lines of unit tests. The vast majority of bugs are avoided by design due to the nature of test-driven development. A few changes/fixes may be necessary in the future, but they're a breeze to implement and test.

Approach 2 produces significantly better results at the cost of larger up-front time investment. The theory is that taking the extra time up front allows you to be more productive toward the end of your project because you're not going back to tweak/fix old broken code; you can focus on using it to get the effect you want and just know it'll work. Of course, sometimes approach 1 is more appropriate to the situation - it's an art form to know which approach to use when.

[Nix]

To me, software engineering is more about placing pieces together, like building blocks, to create larger pieces of software. Software engineering is about using algorithms in a final product and presenting them to the user while the actual devising of the algorithms takes place on the other end of computer science, with "hacking" and even further down, with research and theory.

[_Tommo_]

Interesting perspective. I think of software engineering in a completely different way - essentially as a form of more strictly-disciplined programming which may take longer but produces better results. Suppose I want to write a piece of code that's central to an application I'm developing. Depending on whether I'm in "engineer mode" or not, here are two different ways it could go:

1. I jump in and hammer out the code right away. It's done in a day, and is 800 lines long. There are a few bugs initially, and I may have to go back and refactor it later because I didn't put a whole lot of thought into making the API clean or ensuring that it's easily testable, but in a lot of cases it'll just work.

2. I take some time to plan, design every aspect of the API with great care, and implement the whole thing using TDD with full unit test coverage. It takes a week to finish, and is 300 lines long with 700 lines of unit tests. The vast majority of bugs are avoided by design due to the nature of test-driven development. A few changes/fixes may be necessary in the future, but they're a breeze to implement and test.

Approach 2 produces significantly better results at the cost of larger up-front time investment. The theory is that taking the extra time up front allows you to be more productive toward the end of your project because you're not going back to tweak/fix old broken code; you can focus on using it to get the effect you want and just know it'll work. Of course, sometimes approach 1 is more appropriate to the situation - it's an art form to know which approach to use when.

Dunno, to me a good programmer should be able to take both approach, while dividing "programmer" and "software engineer" means exactly that an "humble" programmer will take path 1, while a full fledged software engineer will take path 2.
To me instead programming is solving problem in the broader sense - so if you are required to do something that you trust it works, you do it using the right tools.
You can't just split the two things, imo.

"Software engineering" in the practice looks much more linked to the years of experience and what you do/earn rather than programming skills, and indeed there are many that plan everything because they can't do anything. Just look in any Italian university.
Anyway that's a gut feeling, I'm sure it's not the canonical definition

[Triplefox]

My personal definitions:

Programming = I wrote code that runs.

Software Engineering = I wrote code that runs, and other people can edit it when I get hit by a bus.

This is really a challenge of degree. The tools get in the way of the discussion. It's easy to harp on "enterprise" stuff that adds meaningless abstraction everywhere, or "proper OO" that turns into a brittle over-inherited mess. But the flip side of it is that yes, you can reverse-engineer the binary after all the source is lost, provided you've got the available talent, and you can, with enough time and effort, unscramble the copy-and-paste spaghetti "legacy" code, but you don't want to be in those positions either.

Those are the life-or-death cases. The ones in between, where the code is bit dirty or the architecture could be a bit better, or someone on the team wrote an really obscure segment, but there's no time to clean it all up, are closer to the "real world."

I also don't see planning as a major part of it. You can only plan well if you've seen the problem before and "built until it broke." That's when you know what to be planning for. "Bad plan is worse than no plan" also applies, since the problem itself tends to motivate deep architecture changes as you get closer and closer to the ideal solution, so early architecture assumptions can really get in the way. In a team you have to coordinate who's doing the work and how to make it work together, of course, but the management is a communication problem, not a top-down idea of "this is how it will be coded."

Similarly, tech/test/build/deploy strategies are forms of planning. You can make a few safe bets on tech at the outset of the project since they're suggested by product needs(it will use xxx algorithms, run on yyy platforms...) but the details of how you test, how you debug, what the coding standards are, etc., are going to vary based on what the problem is; you could argue that using a language like Ruby to write web apps leads to usage of unit tests and stack traces in your regular process, while using C to write games leads to usage of machine-code-level debuggers and manual debugging infrastructure(real-time variable readouts, frame-stepping, etc.) and these differences are just part of the differing problem domains and their requirements, not flaws in one or the other.

A popular strategy of open-source projects is to prototype in Python or Ruby, and then rewrite with C or C++ later. This lets the programmers quickly identify the problem space and create some functionality, and then fix the later issues(performance, compatibility, packaging/distribution, etc.) with the rewrite. The whole way through, they get to use the most advantageous technology for their purpose.

[bateleur]

Programming is all about code.  Focusing on what you're trying to do is software engineering.

You have to realise, I'm a mathematician by training. As such from my perspective "engineer" is a word for student who wasn't quite clever enough to study physics and "software engineering" is a word used by corporations to indicate to me that I don't want their job. 

[14113]

Programming is all about code.  Focusing on what you're trying to do is software engineering.

You have to realise, I'm a mathematician by training. As such from my perspective "engineer" is a word for student who wasn't quite clever enough to study physics and "software engineering" is a word used by corporations to indicate to me that I don't want their job. 

Then you don't understand engineering.

[BorisTheBrave]

I understand his sentiment. Software engineering means writing code that works as part of a team of people, and for many programmers, that is the most frustrating part of the job. Depends on your co-workers, I guess.

[14113]

Yes, I agree with that part, however I feel he is oversimplifying what an engineer does somewhat. Yes, engineers often do more practical work, but they still have a lot of hard maths to contend with.

[bateleur]

Yes, I agree with that part, however I feel he is oversimplifying what an engineer does somewhat. Yes, engineers often do more practical work, but they still have a lot of hard maths to contend with.

Just in case there were engineers reading who might actually have been offended, I should probably clarify that that was a joke. (It's a kind of universal stereotype that mathematicians see themselves as smarter than scientists, who in turn see themselves as superior to engineers, who themselves look down on arts students.)

The point about the "software engineering" label is that in the corporate sphere it's a label best loved by people who do not themselves write code and therefore serves as a kind of warning sign. But of course your mileage may vary.