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

6 followers

10,425 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. 
Joshua Summers
12:00, 15 Jul 20
So based on your experience, where do you feel the greatest value lies in the spectrum of what it means to be an engineer? Or is it person dependent?
Ben Rometsch
12:21, 17 Jul 20
There are a number of things that people starting off in a career of Software Engineering should try and keep in mind.
  1. Never stop learning. Software development is still a very immature discipline. I like to think about it like building jet aeroplanes. After the jet engine was invented, flying on a jet passenger plane was pretty dangerous! Google "the de Havilland Comet". There was so much new engineering that needed to be learnt to get to the point where now it is pretty much the safest mode of transport in the world. The software industry is still building de Havilland Comets to a certain degree. So much is being learnt in terms of best practices, what works and what doesn't. If you don't constantly learn new things, you will be left behind.
  2. You know less than you think. You can wield great power writing software and it can go to your head! Good engineers are humble and never think they either know it all or know better than others.
  3. Stretch yourself. If you know an OOP language, learn a functional one like Elixir or Haskell. If you have spent a lot of time with a very high level language like Python, try Rust. Think of it like a gym. The machine you cant stand the site of is probably the one doing you the most good.
  4. It is an art as well as a science. There is room for beauty and elegance in software.
Joshua Summers
16:43, 27 Jul 20
I sort of feel swamped by things that I don't know, almost to the point of paralysis.
I'm new to Ruby on Rails and know that there is a huge ocean of knowledge that I could keep swimming in, but then again I'm competent enough to build this reasonably functioning Taaalk website. I look at React, which might help me get a job, and unlike with Rails, I know none of that currently. And then there are tangential things, for example improving my git skills.
It feels confusing, especially without a job where problems to solve aren't put in your plate. And it feels confusing because I can do enough to create. I could probably build most things in my mind with Rails and a standard html.erb + scss front end... but while I would learn something, I wouldn't be learning in leaps and bounds in the same way I was when I was learning Ruby/Rails for the first time. I guess what I'm saying is that, in some ways, my ability to create is separated from my need to make drastic educational strides - so it is confusing to know what to focus on.
If you were in my shoes what would you be optimising for? Does it seem obvious from where you're sitting?
Ben Rometsch
15:36, 30 Jul 20
A good rule of thumb for things like personal projects. If you want to learn something new, build the project with new tools, languages and frameworks. If you want to actually build a project, use what you know. So it depends what the point of the project is. I guess if you want to do both you have to just accept that it will take longer using whatever new shiny stuff you’re using. 
Tech and software engineering has always been obsessed with the new thing. People just can’t help themselves! It’s fine if you’re just working by yourself and playing around with a new language or framework, but if you are making those decisions on behalf of an employer with a large team, you can easily burn millions of pounds by making the wrong choice. The hard part of all this is making consistently right choices given varying contexts and requirements. 
This goes back to what I was saying about engineering. It is not just coding. It’s the ability to understand a new technology, digest what is good and bad about it, consider it subjectively and then make a decision based on all that information. Good engineers will be good at that, and will be opinionanted about it as well. Being careful and conservative when they need to be, and working on the cutting edge when it makes sense. 
I would recommend not trying to do 4 new things at once. So if you want to learn Flutter or React Native, don’t then something totally foreign for the backend API. Just take it one step at a time. That way you will strike a balance between the fear and excitement of learning something new, and without the admitted drudgery of knocking out features that have no interesting aspects. 
Follow this Taaalk

6 followers

10,425 views

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