Software Engineering != Coding

I'm a recently trained full stack developer who want's to understand the FULL stack. Right now I think of that as backend + frontend code, but I hear there is more to it than that...
I am the founder of multiple bootstrapped companies. They include web, mobile and infrastructure development agency Solid State Group, virtual office business The Hoxton Mix and, most recently, developer friendly feature flag tool Bullet Train. I've been involved with many more than that, watching some succeed and others fail.
Follow this Taaalk

2 followers

2,467 views

Joshua Summers
15:58, 26 Jun 20
So Ben...
You asked me to choose a picture of something engineered by Brunel, the creator of the Great Western Railway, to represent this Taaalk (see top).
Why did you ask for this?
Ben Rometsch
12:36, 03 Jul 20
Right so yes I've spent over 25 years writing software for people in a professional capacity. As time has gone by, and I've learnt more about the process, I've slowly realised that actually writing code is actually quite a small part of the process. When I was a junior developer I probably spent 90% of my working day sat in front of an editor writing code. And I thought that was the job. Turns out it really isn't! 
I think people both inside and outside of the industry fixate on coding for a number of reasons, and it's quite interesting to ruminate on those, but building software is so much more than writing code. Talking to users, agreeing on features, designing the interface, setting up the infrastructure, testing the platform for bugs, testing it for performance, providing support for it. These are all messy, imprecise things that have very human factors. 
If you are a software engineer you can often seek solace in the code itself. Code is truth. You can't really argue with it. You can't argue with your compiler. It's really easy to fall into the trap of avoiding all work other than coding for these very reasons. But I would suggest that this makes you a really bad engineer! Engineering means getting your hands dirty, either literally in the case of Brunel, or from a human interaction point of view where software is concerned.
Joshua Summers
14:15, 10 Jul 20
So you are sort of saying that an engineer solves problems, and problems are experienced (mostly) by people, so to solve problems effectively you a) have to deal with people and b) have to really know how to solve the problem (e.g. dealing with infrastructure, performance, etc.) instead of only the parts you are comfortable with. Is that correct?
How much of this comes down to the attitude of the engineer? And how much of this comes down to actively studying? 
Ben Rometsch
10:22, 13 Jul 20
In my experience, almost 100% of that learning comes from hard won experience. 
When I studied at university, I was really surprised to discover that the "Computing" courses that I was interested in were labelled as "Software Engineering". I thought it was odd at the time; I never really had thought it about it before, and I was even a bit worried that I might have been signing up for the wrong course! 
I don't think many universities at the time offered "Computer Science" as an undergrad course; it's a very different discipline. 
It took me a LONG time to get my head around the fact that one of the words in the job was "engineering". And really the only way I realised that was after years of working building software. At some point the penny dropped that I was an engineer, and that writing code was only 1 aspect of that job. 
Follow this Taaalk

2 followers

2,467 views

Start your own Taaalk, leave your details or meet someone to Taaalk with.