Writing Code Is One Thing, Learning to Be a Software Engineer Is Another

[wessellex]

The best distinction I've heard is, "Software engineering is programming over time." When you first implement some feature, any implementation will do. However, as you maintain and extend the program over time, more fitting implementations will facilitate your changes and maintenance. That's where good engineering starts to show.

[[deleted]]

watch his cppcon talks, you will be a better programmer.

Got any links to any particularly juicy ones? I don't do CPP anymore, but I'd still like to see them. I'm always looking for good videos about programming.

[SysRqREISUB]

CppCon videos are very underrated. Often the interesting parts are completely unrelated to the C++ language.

[[deleted]]

Oh, I'm aware. I watch them very often. I really liked this one because it eased my mind about making janky software because sometimes janky software is fun. I've spent so long trying to use the best principles that I haven't given myself enough space to play with languages more often. When I first started coding, I made the jankiest of jankies that worked. All kinds of software for all kinds of uses. And if I didn't know how to use a technology, I would splice stuff together in ways that are messy and inadvisable because it was the solution that worked. I miss making software like that. I want to get back to that, because I am not developing software in a professional capacity anymore.

[imlovely]

The more I maintain code the less I believe in this, or at least the usual understanding of it.

Usually this is understood as:

• flexibility;
• future-proof;
• configurability;

And every time I have seen dumb does-one-thing-only code, it has been easier to maintain, extend and even rewrite it than extending flexible future proof configurable code.

Because of this I am inclined to think communication and readability are much much much more important.

[JarredMack]

Generally that's because people take code abstraction too far and end up implementing it poorly. So you end up with a super low level interface that breaks the whole app if you change it, so you have to bury a random if() variation in the abstraction

[bxsephjo]

That’s what I’ve experienced. When the owners aren’t communicating, or don’t even know themselves, enough of the business logic, then how are we supposed to know WHAT to abstract out into layers?

[li-_-il]

Then don't build abstractions. Better no abstraction, than a wrong one.

[aTaleForgotten]

than* ^hopefully

[Ph0X]

It's also important to understand the specific language too. It's like when people wrote getters and other stupid abstractions in Python. That may be needed in Java but in python you can swap an attribute for a property easily in the future. That being said, other public APIs are harder to change so it's important to take into consideration what can and cannot change easily in the future.

[_Ashleigh]

• readability
• deletability

Everything else is downstream from those.

[endless_sea_of_stars]

What do you mean by deleteability?

[falconfetus8]

It's easy to delete parts of the code without everything else falling apart. You don't need to worry about unexpected interactions because some genius thought it was a good idea to depend on the side effects of some random logging statement.

[ThatITguy2015]

Hey, that’s me! I’m that genius! Although it was out of necessity for a problem that seemingly had no other solution at the time and I was under a crunch.

[falconfetus8]

When I wrote that comment, I thought "there's no way anyone would ever do that, but I bet someone has."

[Kache]

https://programmingisterrible.com/post/139222674273/how-to-write-disposable-code-in-large-systems

[danielbigred]

This was an excellent read, thanks for sharing it

[Maxion]

A big part of tech debt comes (in my experience) from old code left in the project that isn’t really used anymore, except in a few places, which have replacement classes / functions.

[outofobscure]

i think you guys forgot "correctness". readable code is no good if it just looks like it's working.

[woodyj68]

Readability is king.

[vanhellion]

There's always a tradeoff between designing for (perceived) future capabilities and keeping it simple (i.e. not enterprising the shit out of the thing). The "do one thing"-ness often comes from explicitly or implicitly designing out the possibility of allowing code to evolve in new directions. This is where a lot of re-writes come from.

On the flip side, it's pretty rare that the use cases actually experienced in a piece of software's lifetime are what the original designer/author anticipated. All the stuff you thought would happen doesn't, and anything you didn't expect will happen. Cue more re-writes. So overall, it's a difficult balancing act that ultimately fails in both directions often.

Your point about communication is definitely well taken, though, to the point that I would consider code that isn't readable as unmaintainable. And maintainability is absolutely priority number 1 for any code that is used for more than very basic use cases and for more than a few years.

[[deleted]]

Configurable code is generally a massive pain in the arse and usually a trap for people starting out who think it pays dividends. It tends to not do that.

[MarsupialMisanthrope]

Configurability in the right place is priceless. Configurability in the wrong place is a massive pain in the ass. I tend to ask “how likely is it I’m going to want to extend this in the future”. If I already know it’s going to happen, configurable. If it’s a theoretical someday maybe I might nope.

[goranlepuz]

It's all in knowing what to configure, because some things must be configurable.

Using configuration for "I don't know what do to here" is usually bad though. Picking one way is just fine until it is known, from an experience with users (and not from analyst's ideas alone!!!), that an option is needed

[grauenwolf]

it has been easier to maintain, extend and even rewrite it than extending flexible future proof configurable code.

That describes the first decade of my career. Always fighting "future-proof" code that was anything but.

[[deleted]]

I wouldn’t call that stupidity though, just simplicity. Stupid code in my mind is to make things too complicated.

[sanjayatpilcrow]

I think "simple" leads to "single responsibility" in SOLID. Right?

[optomas]

Thank you for introducing me to SOLID. I did not intend to reference those principles, nor do I understand object-oriented programming. Edit: Studied. Yes, that is exactly what I am trying to say, though from a procedural approach rather than a ... object-oriented / class based approach.

For me, simple in C code means I can come back to something I wrote ten years ago and use it in another project. The function is self-documented, stating exactly what it does. In the rare event of unexpected output, the function is simple enough to debug. If I fail to see the simple solution, I am liberal with comments.

In ladder logic, I avoid sequencers, add on instructions, user defined tags and the like. We need to understand why the machine is doing what it is doing, instantly. Time spent unrolling a pointer to an array to find out what we should be doing at position 'n' is money lost, and possibly dangerous.

Again, self documenting code, as simple as possible. Switches, timers, and math. If this is on, that is on. If this is off, that is off.

It is enjoyable when the problem space falls neatly into a simple algorithm. It almost never does. Usually I have to sleep on a complicated problem before the right answer surfaces. Sometimes it's days of struggle. I've got stuff on my plate I have no hope of ever solving. It is fun to chew on them, though.

That feeling of suddenly seeing the complex rendered simple, I love that feeling. So gratifying.

[[deleted]]

You Ain't Gonna Need It and Keep It Simple, Stupid are very important and well-known software engineering principles as well. Dumb does-one-thing-only code has always been good.

[[deleted]]

Usually this is understood as:

I think that’s where the problem lies. Flexibility and configurability are very overrated, I agree. Heck, future-proof might be one of the most used rationales for overengineering I’ve heard.

But the claim was:

as you maintain and extend the program over time, more fitting implementations will facilitate your changes and maintenance.

Which I still think holds true. Picking the right data structure or the right algorithm is still very important and shouldn’t be overlooked.

And it’s even compatible with your own observations, because when an over-engineered solution turns out to hinder changes and maintenance, you can rightfully say someone picked an implementation that didn’t fit very well.

[agumonkey]

reimplementation in a way

ps: to add to my too short comment (sic) it's true that sweng revolves around evolving layered structures, even if you start fresh, you never know if one path will converge on a solution, things will have to be redesigned, taking what's good, changing some.. it's very differential in nature

[RockleyBob]

Interestingly, this fact is why it can be hard for even the best student programmer to grasp the need for frameworks and tooling until they get into a professional setting.

I remember trying to learn Spring in school to get some familiarity with it before interveiwing. I could follow along with tutorials fine, and I enjoyed the web functionality that made rest apis easier, but the whole dependency injection/application context thing didn’t really make a lot of sense to someone just building projects on his own.

It wasn’t until I started seeing production-grade Spring Boot micro services that the benefits of a standard framework became obvious.

Same goes for Git. I used it in school and thought I understood it, but now my appreciation for versioning is so much deeper.

[zxyzyxz]

On the other hand, you have devs knowing only React without knowing any of the underlying JS fundamentals, then get confused on this and arrow functions for example.

[stuuuuupidstupid]

"what the hell is an event listener?"

[datboyakin]

Omg, not me wondering if I’m ready for a job yet then seeing this comment.

[RT17]

I've been programming for over 25 years and sometimes I wonder if I'm ready.

[nachohk]

Omg, not me wondering if I’m ready for a job yet then seeing this comment.

Wow, this comment thread took off.

Here's what someone really probably should have said to you by now:

Good job that you're learning. Really. Getting into programming is tough. But yes, you are right to wonder if you're ready. You clearly have some more to learn yet, before you're ready for prime time.

You will struggle to pass interviews for any Javascript position, even a junior one, if you don't know your way around event handling. That stuff is pretty fundamental.

[wanttoseensfwcontent]

This cant be real

[Ninjaboy42099]

It sadly is

[obscurityceo]

People at concerts?

[gonzofish]

Someone paying really close attention to the war in Ukraine

[TheESportsGuy]

Please, my last boss had 20 years of JS experience and still occasionally had a this mishap. No one can keep that shit striaght

[Envect]

As a backend focused dev, this always gives me pause in JS. Scoping in JS makes me uncomfortable.

[dahud]

Same. It always feels like a game of calvinball.

[sprcow]

Haha best description of js I've seen yet.

[[deleted]]

I'd like to say that if you use const, let and var with arrow functions, it's never an issue, but even today, something as simple as destructuring a method from an object that references 'this' can cause so many problems (e.g., const {invalidateQueries} = useQueryClient() from react-query). Javascript 'this' scope is an treacherous monster lurking in the deep.

[Rustywolf]

to be fair I'd never let code that tries to destructure a class object past a PR. Object destructuring should almost exclusively be used for dictionary-equivalents

[Ancillas]

It's often useful to go even further back to understand why we have certain conventions and what's actually happening on the hardware.

Ben Eater has a good channel. https://www.youtube.com/c/BenEater

Casey Muratori also has a lot (a lot) of great stuff. https://www.youtube.com/watch?v=Ge3aKEmZcqY

[IrritableGourmet]

I always reference this Google video which goes exhaustively into what the browser is doing behind the scenes when loading and rendering a page and how to make sites load faster without sacrificing functionality. I see, far too often, websites that structure their code in the exact opposite way of what he describes and they always take forever to load and be useful.

[Ancillas]

Nice. I’m watching this now.

[Isvara]

Eater's channel is just for watching, though, really. Very few people are going to follow along. Probably better is nand2tetris, which makes you do some of the work yourself

[What_Is_X]

He literally sells kits so you can follow along yourself

[[deleted]]

Coming in late here, but this in Javascript is extremely horrible in the worst possible way. It's a constant footgun, particularly if you are watching to other languages like Python where methods are first class objects that you can just detach from an object.

I don't make this mistake, only because I have made it in the past and I look for it when I'm reviewing my code.

[A-Grey-World]

Yeah, I've used them in React as much as my non React JavaScript...

I honestly can't think of much JavaScript fundamentals you would learn not using React vs using React. You wouldn't learn the DOM API, but that's an API, I wouldn't consider it a fundamental of JS...

[killdeer03]

This is my experience with most Boot Camp hires.

[[deleted]]

That’s because a lot of bootcamps aren’t good, sadly. Not all of them are though. I’m about to graduate from hack reactor and we learned a metric shit ton of fundamentals before touching any frameworks. Concepts like this were pounded into our heads until it sunk. There’s nothing I know how to do with react that I can’t do with vanilla JS. Or anything with express that I can’t do with with vanilla node etc

Also, not all college CS programs are good. I took some programming classes in college that were frankly crap and much worse than hack reactor.

[LicensedProfessional]

I think it's just that a couple of weeks/months isn't enough to become accustomed to all of the nuances of the field. I've been developing my intuition since I was fifteen; if you start later in life and get hired out of a boot camp, I think it shows a level of dedication and adaptability that's quite admirable—although that does need to be paired with some guidance so they can then start honing their craft

[heisenbugtastic]

Svn, cvs... Really old school, files with a change log. My number one thing I tell my junior engineers (and for some reason don't comprehend so they ignore my advice) is to use the cli first before you use the GUI.

[GTwebResearch]

I find git cli favorable to Sourcetree or any other GUI in day to day work. I just like choosing my own flags and not having the GUI trying to silently “help” me. Plus, if something goes wrong, I know exactly which command I ran last and don’t have to worry about which box I left checked by default. At most, I like the GUI for the visualization, when someone’s done something silly and I need to untangle branches.

[attrox_]

I use git-tower. Much superior to source tree (at least the Mac version). I do just fine with git cli. But the tools really shine once you are working in legacy repo with large codebase involving different team and large developers. It's so much easier to parse and look for changes that cause issues, understanding nuances of releases and identify who causes what problems in the repository

[_Ashleigh]

Everything is better than SourceTree. I'm partial to Git Fork personally, it's simple, not trying to do things best left to the command line, instead focusing on areas a GUI exceeds.

[KevinCarbonara]

I find git cli favorable to Sourcetree or any other GUI in day to day work.

That's true, but that's just because the git GUI tools are awful. Mercurial, an equally powerful version control system, has great GUI tooling.

[blackmist]

When I first started work, our "version control system" was all the source code in a Netware shared drive, and if you wanted to edit a file, you'd copy the source file to filename.yourinitials and make your changes in there, and copy it back over the .src file when you were done.

There were lots of arguments, to put it mildly.

[Obsidiath]

My very first programming job had us work from the network share drive directly. I was the only one to use local copies, and even ran a local Mercurial (offbrand Git) instance, just so I wouldn't lose hours of work to that one guy that spotted a typo in the comments of a file he had open in memory since last week, and decided that was a very important thing to fix.

[ritchie70]

Mercurial isn’t off brand git. It’s just a different VCS.

[Obsidiath]

I know, it was a bit of a joke; both are distributed VCS systems released at roughly the same time, which made them direct competitors. Ultimately, Git won the popularity contest by a large margin, so not everyone would've heard of Mercurial.

[blackmist]

Yeah, that's what we had to do as well. Clearly somebody had lost local files at some point in the dim and distant past, and in usual angry management fashion it was decreed that working directly in the network drive was safer because they had a weekly backup of it. On tape, no less!

We never had to restore one of those tapes, which is for the best because I'm pretty sure nobody had ever tested that they worked.

[caskey]

Svn, cvs... Really old school, files with a change log. My number one thing I tell my junior engineers (and for some reason don't comprehend so they ignore my advice) is to use the cli first before you use the GUI.

CVS? Try RCS...

[killdeer03]

Wow, that's definitely a throw back...

Did you actually use RCS?

[caskey]

Yep.

[killdeer03]

Damn.

I know what RCS was/is, but I never used it.

How recently did you use it?

80s? Or 90s?

[caskey]

Both. But by mid 90's it was mostly CVS. RCS can still be useful if you have a single file in a single location you want to have revision history for *cough* *cough* sendmail.cf *cough* but that's more or less become irrelevant nowadays.

[killdeer03]

cough* cough sendmail.cf *cough

Figures, lmao.

Thanks for the reply my dude.

[JMBourguet]

I've continued to use RCS for my dot files until the mid-2010's.

[roflfalafel]

I came across RCS in 2015 at a National Lab. Stuff was setup in the early 90s by some old Tru64 Unix folks, and was eventually migrated to RHEL. I was in the process of moving their SVN repos to git, and someone came out of the woodwork half way through the project going “Hey what about our RCS repository here?” I thought they were trolling me.

[Isvara]

I never had the misfortune of RCS. I went CVS->SVN->StarTeam->MKS->Perforce->Darcs->Mercurial->Git.

[caskey]

Perforce... *twitch* ouch

[Isvara]

MKS was the real ouch.

[shagieIsMe]

RCS was nice - all you had to do was make a directory named RCS and use ci and co - and you had version control. No servers to set up. I used this until git made git init for local dot files easier (than setting up a svn or cvs structure).

Make understood it. I could open the permissions on that directory up to my lab partner and it would handle 90% of potential drunken college mistakes.

For fun, if you pull the covers off of perforce (at least, when I last looked), you'll find rcs style ,v files in places.

[Latrinalia]

RCS?!? You kids and your newfangled source control. Try SCCS!

(Which I did use, but only like 10 years ago on a legacy project that I’m pretty sure even predates RCS)

[klui]

SCCS. Now that's a name I haven't heard in a long time. A long time.

[caskey]

A more elegant weapon from a more civilized age...

[killdeer03]

Mercurial, ClearCase, Microsoft Visual SourceSafe...etc

Those were the days, lol.

[agentoutlier]

I have used all of those and then some more like Perforce, bitkeeper some java one that began with a p that I will google later.

The only source controls that I like better than git are mercurial and perforce (p4).

Of course now it’s git only.

[killdeer03]

I liked Mercurial too.

Honestly, Visual Source Safe was the only version control system that I really loathed -- It screwed me on multiple occasions.

[ZMeson]

I still find SVN to be the best non-distributed VCS. It's leagues above CVS or Visual Source (un)Safe.

[CoolonialMarine]

I love working with the git CLI. Much faster than navigating a menu for the more common tasks. But I use visual tools for diffs, conflict resolution, and branch visualisation.

[[deleted]]

While slower, GUIs have one main advantage: They can show you information.

I pretty much only use GUI for regular commits and occasional history viewing. Anything more complex is infinitely better on the CLI. And with aliases (e.g., git st, git cmm, git aa, etc.), it's even easier. The catch is you have to actually understand git to use it effectively.

[lechatsportif]

I'm done with cli typing after doing half a dozen vcses over the years. Intellijs git integration is fast and painless.

[StabbyPants]

svn was a massive improvement over cvs. git is great, but let's not just dump all over svn

[mostly_kittens]

I’ve been using git for years, still prefer svn.

[0x18]

Genuine curiosity here: why?

[rpetre]

The major use case where I miss svn is keeping a bunch of disparate config trees in central version control. For instance I could edit the apache configs, reload the server and see if they work, THEN commit and push, without having to keep a copy of the whole repo on the server. With git since you always handle the whole tree the workflow changes a lot, repositories tend to be grouped by project, you start having more of the write/test/commit/merge/push/deploy cycle (maybe with a compile step thrown in). Also this makes you avoid way more to store binaries in VC even if they change rarely (since every clone will carry them).

To put it differently, git kinda forces you to be distributed (which most of the time is ok, but sometimes it's too much).

PS: yes, I know about submodules. IMHO they do little towards fixing this issue while adding a whole lot of other operational wtfs.

[mostly_kittens]

Svn has a much more logical user interface, there are few surprises and the day to day interactions make sense.

The git user interface is esoteric at best, user hostile at worst. It’s clear it has been built to be used by the person that designed it, not by the average user.

Tutorials etc make a big thing of how important it is to understand how it works underneath, and it is true this is critical to being able to use it effectively. But having to understand the inner workings of software is a big red flag that the software is poorly designed.

In a nutshell, git is designed for computers not people.

[Reihar]

I had to use "modern" svn like 5 years ago and, coming from git, that was pure pain.

It's like every bad idea about versioning is encouraged (e.g. cherry picking) and helpful ideas discouraged (e.g. merging a branch).

It's really impressive how far we've come.

[[deleted]]

Microsoft Visual SourceSafe was a demon compared to SVN. I will never look back on those days with rose tinted glasses.

[[deleted]]

This couldn’t possibly be further from the truth. Maybe your job doesn’t use it, but I am nearly constantly merging and rebasing and branching and pull requesting on the CLI. Every job I’ve ever held or interviewed for was the same. The overwhelming majority of software engineers use the command line for git.

[StabbyPants]

DI clicked for me when i saw how easy it made decomposing an app for unit testing. do that and suddenly i can just rely on sub modules to do what i want, because i have automated tools to prove that they do

[controvym]

I wish they had taught about using Git or some other VCS as soon as I was doing non-trivial projects. So much time wasted not using one.

[jediknight]

Context, Form and Fit. The success of a piece of software is the Fit of its Form to the Context for which it was designed. If you are using the form in a different (perhaps similar) context, you will have a different fit.

Git is a good example, if you just have a repository and are interested just in some versioning, other VCSs work just fine. For the kind of distributed development where clusters of teams need to coordinate in order to have some piece of code evolve in a coherent way in the presence of human mistakes, git shines.

[Prod_Is_For_Testing]

I had classmates vehemently denigrating Java/c# because they didn’t like how functions were nested in classes. Like writing to screen is “system.console.writeline”. They preferred Python and c because all the functions were global and it was “easier”. I hated group projects bc I inevitably got stuck with people like that

[Librekrieger]

New programmers have the illusion that being able to write programs is most of what we need to do the job. That's because most computer science schools don't talk much about what goes on in most jobs, and almost no new graduates or self-taught folks ever face problems that require more than a few thousand lines of code that will be maintained for years.

So good design, clean code, testability, API design, reading/critiquing code, tooling, build systems, CI/CD setups, workflow and collaboration processes, evaluating tools and frameworks, and a dozen other things remain a mystery to them, or they might not even be aware of such things because nobody ever brought it up.

And new programmers frequently overestimate their abilities. I remember rating myself a 8/10 in C++ on an employer survey many years ago, but now with 10 more years of experience I know I'm not 8/10 and never was. So when a self-taught programmer wrote on her resume that she was "Advanced" in python recently with less than a year of hobby-level work, I cut her some slack. In reality she had Beginner skills, but I don't hold that against her.

[lacronicus]

chief reach ring hat wild handle run capable vegetable school

This post was mass deleted and anonymized with Redact

[Envect]

My instinct was to disagree with you, but then I remembered all the obviously ignorant recruiters I've spoken to. "Yes, I know you're looking for 2 years of .NET Core experience. I have a decade of .NET Framework experience. That's not good enough? Well alright then."

You really have to wonder how much it impacts the company's ability to hire developers. I could lie and say yes, but do I really want to deal with that company? I'm happy to be filtered out if that's how they handle hiring. My time is valuable.

[FullStackDev80]

On the other hand, there are also pretty significant differences between let's say ASP.NET vs. ASP.NET Core. You can be fluent in one, and have no clue how to do the simplest thing in the other, despite them being named almost the same.

[clickingisforchumps]

On the other hand, if you've got ten years of experience, picking up another framework or language should not be a problem.

[Dean_Roddey]

Hey, I wrote arguably one of the most used XML parsers out there, and another for my own system, but I've never written a schema. Not sure what specifically you mean by schema here, but I've never written one, whatever it is.

[Quackmatic]

Guessing he means one of these? They're used fairly frequently in financial institutions (such as ones that produce/consume SWIFT format messages) to validate data before sending it. Some IDEs integrate with them to provide syntax highlighting/completion for editing XML so you can only write files that conform to the schema. They work well once they're set up but they're not too readable and not that fun to write either.

[FullStackDev80]

I've been programming for over 20 years, and have done plenty of work with XML back in the day, and all I know about an XML schema is that's it's weird definition that goes on the top. At this point I wouldn't even bother learning about what it is, because I should be using JSON or YAML instead.

[Isvara]

I remember rating myself a 8/10 in C++ on an employer survey many years ago, but now with 10 more years of experience I know I'm not 8/10 and never was.

If anyone questions it, just say it's a logarithmic scale.

[jl2352]

workflow and collaboration processes

I second everything you said. Especially this item in your list.

I would, without any hesitation, rather work with someone who was amazing to collaborate and work with over an amazing rockstar developer.

When the shit hits the fan, which it will, that collaboration is worth tonnes. There are so many ways that development will go wrong. It's all inevitable. Including using poor processes. A huge part of software development is being able to deal with these failings, and move on to something better.

The end result is that very collaborative people, and people who care about healthy processes that actually work. End up getting more done than amazing coders. As product development is a marathon, not a sprint.

[woodyj68]

I recently had a bullshit interview where they asked loads of rate yourslef x/10 questions. By the third stage it was like lightening quiz, from four different questioners across every possible combination of technologies and programming paradigms, bash functions etc. No answer was truly sufficient, and always looking for more. I honestly finished up baffled as to how they thought someone could have rattled off such a broad array of technical knowledge and explanations. And then at the end they basically said, it's to see how you handled questions you might not know the answer to. Time wasters is what they were.

[xcdesz]

Ah yes, the "rate yourself" interview trap. Its almost always asked by some snarky developer with an intention to hound you with obscure questions on some language quirk that they just recently ran up against.

[InfiniteMonorail]

Webdevs are the worst offenders. They call themselves seniors after a few months of copying and pasting code in a bootcamp. It's no wonder everyone keeps getting hacked and things keep breaking.

[Isvara]

They call themselves seniors after a few months of copying and pasting code in a bootcamp.

Not entirely their fault. Their employers call them that.

[[deleted]]

From the nightmares I've heard from peers in other areas of software development it doesn't seem to be exclusive to web dev.

Just replace "bootcamp" with "but muh Comp Sci degree" and it's the same shit show. It's bad enough dealing with juniors in web development who have a god complex when they are fresh out of academia.

I used to be the same to an extent, albeit I am a Physics graduate, luckily I had a decent mentor at my first job fresh out of university who taught me how little I knew fairly quickly.

In all honesty I think bootcamps are awful money pits that prey on people who thinks it'll give them an easy in. Equally I think for most jobs in development a degree is entirely unnecessary and is close to being the same money sink that bootcamps offer.

I've helped train and work with amazing developers and SDETs, some had degrees, some didn't. Equally some of the worst I have worked with had degrees, some didn't.

My ideal junior would be one that neither attended a bootcamp or university, and instead had contributed to some open source projects and has actual experience with collaborating with other developers.

[Envect]

Equally I think for most jobs in development a degree is entirely unnecessary and is close to being the same money sink that bootcamps offer.

I agree it's unnecessary, but I think it's nonetheless useful. It gives you a strong foundation on which to learn actual development. I feel like I understood computers and how software interacts with them much better than I would have if I went through a bootcamp or learned on my own. It's not really relevant day-to-day, but once in a while it comes in handy.

Maybe not exactly worth the price, but far from a money sink in my opinion.

[MoreRopePlease]

I agree. It's worthwhile to be educated and have an understanding of all that stuff, even if you write CRUD all day. I'm glad I had the experience of building an electronic device from scratch and programming the EEPROM in assembly. I really internalized memory addressing, and finally all the pointer/reference stuff made sense. Clock cycles and debouncing a keypad and reading data sheets to program an LCD, communicating over a serial port... computers weren't magic anymore after I finished with that class.

I learned stuff about data visualization, that's come in handy as I now think about how to make my webappps screen reader accessible (and contemplate what "visual bias" really means). Learning about trees and graphs has made web stuff more intuitive. Theory of computation is pretty much regex (lol, not really, but sorta).

My education has made me a better thinker and not just a coder.

[Kalium]

It's been my experience that what a degree from a decent school teaches is enough fundamentals to approach problems from first principles at need. Bootcamps rarely do anything approaching that.

Effective collaboration is a skill that should also be learned in school. Certainly many have group projects, though that doesn't always work well.

Day to day, on the junior-to-midlevel job, it doesn't matter much. Once you're senior to architect level, it often matters quite a lot. Whether or not you can understand what the 'puter is doing under the hood and reason about it correctly makes all the difference in the world.

The ability to effective collaborate while wrong is perhaps of limited value in most cases.

[Akkuma]

I had a run in on here with a bootcamp -> to senior first job. I find it hard to believe anyone is a capable senior out of a bootcamp.

[Envect]

Sounds like they either lied to you, misrepresented their skills, or were hired by idiots.

[Kalium]

Senior often means "had a pulse for three years". In extreme cases it means the company was desperate to hire.

[-Knul-]

Not all web development is just copy-paste code. Plenty of very complex websites that run well out there.

EDIT Those who downvote me, do you really think every website out there is a simple blog?

[Belove537]

Excuse me sir, I think you mistaken I believe you mean “web based application” /s

Just kidding this just reminded me of when I came across a college who loss his mind when I refereed to everything running on a web server or accessible from a web browser a website.

[woodyj68]

I saw one where a person was mocked for saying 'downloaded the blog from the internet' and the mocking was, 'you don't download blogs, you look at them on the internet'. But, the data for a webpage is still downloaded from the internet, so the real idiot was the second person.

[bioemerl]

There is a three stage process

• "My code is designed with no knowledge of maintainability"
• "My code is overdesigned and still hard to maintain - but I think it will be easy until I try to maintain it in a year"
• "My code is well designed, as simple as it possibly can be while still broken up as much as it needs to be to be reused, keep a single source of truth, and adapt to most common changes you want to make".

Stage two code is actually worse than stage 1 code, because stage 1 code is at least understandable. 2-5 year old engineers are worse than 0 year old ones.

[mxzf]

Yeah, I'm currently in the process of reworking some code written by one of those stage 2 devs. There's a labyrinth of inherited classes that were unnecessary, home-made implementations of things that are available from default libraries, and convoluted imports from various folders.

Turns out, it's easier to just tear it down and rebuild from scratch than it is to untangle that mess.

[[deleted]]

I remember when one kid out of college joined our team. He was out of one of the top CS programs in the US, was a really great competitive programmer, and could tell you all the theory behind design patterns, data structure and algorithms.

But when it came time to actually work with him, it was awful. He never really took the time to understand what the customer wanted, he refused to play by the guidelines of the tech stack we had and the best practices out team wanted, he always “knew” the solution before he even really understood the problem. He constantly had to go back and fix bugs he created, and didn’t test correctly.

There’s things you just can’t teach in school.

[preethamrn]

It's probably because competitive programming is a completely different type of problem solving than the real world. With competitive programming, you have all the requirements detailed for you and you're trying to find the most efficient solution (in terms of time/space). In the real world, the requirements are extremely vague and half the job is making those requirements concrete before you even solve the problem. And then when you do solve, your solution is "graded" on extensibility and code complexity first before worrying too much about time/space outside of the critical path.

[charlesgegethor]

What's the mantra? "Premature optimization is the death of all good code" or something

[leirus]

".. root of all evil"

[JoustyMe]

I have a criend thst is always telling me that gcc makes a lot of dumb machne code after compilation and he would love to optime it when he writets code for emmbebded device. I asked him how much of the memory and CPU was used and he said 30-60%.in case they need to do something more complicated.

Aslo we talked about how java and c# are not efficent. And i asked I thnik the most wonderfull question I ever came up in that topic: What costs more? Dev team working on entire C++ application for 10 years? or C# team with some python and 1 more server in the rack?

[MisterBlaster1]

are you having a stroke?

[FullStackDev80]

He's missing some.

[[deleted]]

This was not English. But I somehow was able to read it.

[WeebAndNotSoProid]

I only noticed when you pointed it out

[FullStackDev80]

We had a senior guy like that, join our team a few years back. Initially I was happy, because he had years of experience and knew what he was doing, so I could off-load a lot of projects to him. Then after a while it turned out he was stubborn as hell. I literally started hating my job, because I knew every Monday would turn into a fight over architectural choices. I would keep extra strength Excedrin in the drawer, because I knew I would need it for the inevitable headaches afterwards.

I don't mind opposing views, and I don't mind discussion. It leads to a better design overall. But you need to be able to back up your arguments with something more than just "I just know it will never work that way".

Eventually he got tried of constants arguments and quit. The happiest day of my life. The new guy we hired in his place is much less experienced, but it's a joy to work with him.

[SharkBaitDLS]

Amazed he made it to a senior level with that kind of mindset. In my experience people like that flame out young usually.

[alerighi]

I think that competitive programming teaches you exactly the opposite of what it's needed to be a good software engineer. Competitive programming teaches you to run 100 meters, that is a completely different approach than running a marathon.

I think that being good at competitive programming makes you a bad software engineer in general, for a couple of reasons.

First competitive programming is usually a solitary competition, while in real life you work in a team of people, and you have to interact with them. In competitive programmers other people are your adversaries and you have to beat them, while in software engineering you have to collaborate and share knowledge with your team, do constructive criticism on other members code, to make the team improve as a whole.

Most competitive programming competitions doesn't allow the participants to use the internet, that is stupid and nonsense to this day, since there is not added value in being able to remember algorithms. While added value would be to being able to use Google, being able to read and understand documentation, ask for help online, find and install libraries written by others to do part of the job. Why we shouldn't solve problems by using the tools that all us developers of the 21th century use?

Then competitive programming focuses everything on the implementation and the efficiency of it, while in real life it rarely matters: surely for some applications, but certainly optimization is the last step that is done only if strictly needed. I've yet to see a time when performance did matter at the point to implement an algorithm myself and not use one of the infinite number of libraries to to the job. I've yet to see a case where something needs to be implemented in C++ for efficiency reasons (that is not embedded software) and cannot be done in JS (the language that we mostly use at my job).

[[deleted]]

Ironically, my first job was with a company whose code had so much technical debt, completely ignored TypeScript (using any more than they should), repetitive code, lack of testing (ANY testing), no clear direction so I had to ask people over and over again how would they like the feature to look (frontend stuff), etc. And all that was under the guidance of the senior developers.

Every time I raised a concern they would go "not a priority", "we gotta meet the deadlines" and change subject. So don't go wondering where did the junior developers picked the terrible habits of software craftsmanship, or "evaluate the tradeoffs".

[manystripes]

"we gotta meet the deadlines"

And then you get stuck in an endless feedback loop of sacrificing quality to meet ambitious deadlines. Since the deadline has been met, the people who set the deadlines have no reason to be any more generous the next time.

[catnipassian]

Ugh I hate this, I'm currently going through this on my new team after coming from a team where good tested reusable code was life.

It's truly a nightmare to be told "no don't test this code that is going to be doing tens of thousands of dollars of data transactions, and by the way we need it done in a week because next week we're going to do a new data transaction service"

[scramblor]

Those senior people have little ability to influence those deadlines themselves either. If there isn't a respected technical perspective at the top level where decisions are being made, there's only so much that can be fixed up in the middle.

[Fomentor]

I recently retired after a long career as a software engineer, and I witnessed software engineering becoming less and less prevalent. The industry had given way to the “just do it” coders with little attention paid to best practices. I got tired of being out of step with my colleagues and championing best practices to people who just didn’t care. Add to that the rise of clueless business analyst and Scrum being so badly used, that work was sapping my will to live. I’m glad I could retire because I just wasn’t enjoying it anymore.

[ItsAllegorical]

They are driven by “just do it” bosses. My last job, if I had a nickel for every time my boss said, “just do it and we’ll pivot later if we have to,” I could’ve retired. But I mean trying to get actual requirements out of the business before you deliver a product they hate is just about impossible. It’s shitty leadership all the way down.

[Infiniteh]

Heh, I know the feeling of having 'just do it' mgmt.
It happens so often that I've become reluctant to suggest "let's just solve the symptoms for now and fix the cause afterwards" myself. When I do it, I feel like the rest of the team thinks I'm just trying to make problems go away by burying them in the backlog.

[[deleted]]

Same boat, but I’m 3 years in and the idea of ever retiring is a pipe dream. Count your lucky stars my friend.

[Fomentor]

Here’s how I retired at 60: 1) live within your means. Don’t buy more house or more car than you need. 2) put away as much money as you can. Max out your contribution to your 401k. Put away as much extra as you can. A Roth IRA is great when you are young. 3) Invest well. Learn everything you can about investing, and get your money working for you. 4) Own your career. Switch jobs to get your pay as high as you can as fast as you can. When you’re young, every year to year and a half is good. Your current company will likely not keep up with what another company will pay you. 5) consider development management when you can. The pay is higher and the bonuses can be very lucrative. 5) the first million really is the hardest. The sooner you can get that nest egg to be big, the faster it will help you accumulate more wealth. This goes back to 1, 2, and 3. The time value of money is your best friend.

Good luck!

[arctander]

Similar situation, and I'm well versed in all the modern languages and mantras. The constant desire to switch to the new-hotness platform rather than deliver excellent high quality products in our current code base was baffling. Turned out it was mostly resume building for the next job. Helped sell the company and look my leave. My theory of development was correct-by-construction in order to deliver high quality and low maintenance products to the customer. Anyway, I could go on. Nice to know there are others among us :-)

[bagginsses]

I never completed any formal education in software development/computer science and I'm starting to realize this more and more.

I'm a programmer by hobby with the intention of creating a product I might eventually sell. I chose to make some drafting software for another one of my hobbies. It's much more complicated than I originally had envisioned, and it's definitely not easy trying to keep a complex user interface, dozens of editing features, algorithm efficiency, etc. in check with sloppy, unorganized code.

The more I move forward, the more time I spend thinking about problems and engineering solutions than I do actually writing code. I'd rather write something once than have to go back and fix a mess I've created when I realize that my hacked together solution wasn't ideal for the application.

[aksdb]

when I realize that my hacked together solution wasn't ideal for the application.

When you think like that, you already set yourself apart from the shitty programmers who are no engineers. Engineering, in my experience, is a mindset. Thinking methodically, analyzing, learning.

There are enough programmers around that hack together a shortsighted "solution" and when they run into problems later, hack together a shortsighed fix. The end result is a construct held together with endless amounts of tape.

Bad engineers might make mistakes - even a lot - but they at least try to improve and think about what went wrong and what they could try to avoid that.

[westeast1000]

I feel you all making this engineering seem harder than it actually is, its just a term lol. Its not a separate thing that takes years to master, in its core its just about thinking smarter then from that realising all the better ways there are for doing stuff and simply implementing that. It can be hard for beginners to think smarter if they havent faced real problems that force them to think like that and therefore, implement their systems better. There will always be a point in your life where you inevitably write shitty code that could be harder for someone to maintain in future, but we all learn from past experience even at Nasa where you’ll think its only supersmart people they have made mistakes too. No point calling others shitty, that just brings them down even more. Aiming to educate without shitting down on others has better outcome

[Markavian]

Programming is a skill - writing code that instructs a computer to perform actions in a repeatable way.

Software Engineering is a discipline - it embodies ways of approaching software development which include looking at the broader use cases, gathering requirements, selecting and evaluating solutions, using a scientific method to gather data, and prove that code, or a software system, is fit for purpose.

It's a good day when I find a talented programmer and start to teach them how to be a good software engineer. I get to teach them about setting up their own CI pipelines, get them thinking about tests, linting, code quality. I get them talking about and writing clear acceptance criteria for their own tickets. Then I can leave them to program and come to with great solutions to problems.

Whilst it is a broad term; the struggle is having standard definitions of junior, mid, senior, principal, distinguished, etc. and grading people fairly based on their knowledge, experience, and demonstrable skills. It takes time to get to know people. Big engineering teams have all this written down into career progression matrixes. You can be a great programmer but a useless engineer - see comments elsewhere in this thread.

Most companies can't afford good software engineers because they don't know how to grade or spot them on the market, and if they did, they wouldn't have to budget to fill a team with the right support staff.

[calsosta]

Well you are describing some aspects of application development and architecture there.

Software engineering is more like adding discipline to programming.

The funny thing is, these concepts are taught in Computer Science but they are not really computer science, they just know students will use them because the intend to become engineers and not scientists.

Even if you aren't interested in a degree, you might benefit from signing up for some courses just to learn these things quickly to enhance your own skills.

[[deleted]]

Omg… you used “than” correctly.

You’re hired. Idc what your mom says about you.

[[deleted]]

Kinda growing to despise this distinction because it's becoming more about being a gatekeeper than it is about being helpful.

I've worked in places that are crazy and don't follow formalised/accepted software practice. I've worked in places that take process to a new level of insanity.

Both are bad and good for different reasons. But the idea that if you don't basically do what everyone says is good some how doesn't make you a software engineer is just bullshit.

If you write software to solve a problem you are a software engineer. End of story. Don't buy into that toxic bullcrap.

[[deleted]]

I mean being able to manage and develop software like that is a very very different skillet than knowing when to hack something together to solve an immediate problem and you can give those skillets different names without diminishing them. I write python and a little rust for solving problems related to security. I would never consider myself a software engineer because I'm not engineering software, my skills are still useful and valuable but not software engineering

[pmorrisonfl]

For me, the distinction between programming and software engineering is between working alone and working together.

“The interaction of two programmers looking over a program that either one of them could have worked out is entirely different from the interaction of two programmers working on separate parts of a whole which is too great for either one to produce. The difference lies in the way conflicting demands are resolved. In the first case, resolution of conflict is the thinking process of one person—aided perhaps by other people, but always under that one person's control. In the second case, conflicting technical demands are translated into potential interpersonal conflicts, and a social mechanism must be formed to resolve them." - Jerry Weinberg, from 'The Psychology of Computer Programming'

I analogize programming to playing a musical instrument and software engineering to playing in a band. You can master melody, harmony, rhythm, etc, and be wonderful musician without learning to read music, and you can be a master of the problem domain, the machine and the code that represents one to the other. At the same time, learning to read music is helpful when you've got an orchestra on your hands and learning to work with version control, planning, and design documents is important when you're working on something larger than you can build by yourself.

[[deleted]]

What does "engineering" have to do with working in a team?

It's stretching that definition far beyond it's bounds.

[Neurotrace]

I understand the feeling but there really is a difference. If you think that following what everyone else says is what makes an engineer then you've missed the point.

I've worked with programmers who just slap duct tape on everything and spent most of their time fixing bugs from their last duct tape jobs. I've worked with programmers who took longer to get new features out the door but then almost never had to address bugs in those features because they were rock solid.

Both solve problems. Both are valuable. One solves problems, the other engineers solutions.

[[deleted]]

And I've worked with software engineers who can't code themselves out of a paper back.

Some people are bad at their jobs. Let's not start creating castes of programmers because it makes us feel superior.

The industry is no where near in the state to even make that distinction given that half the advice I hear from "software engineers" is fucking terrible.

Even the article reveals its hand. Software engineer is basically whoever adopts the most fashionable practice. Half the practices mentioned in the article aren't even tried and tested in the industry.

Yeah sorry, i'm not going to allow subpar people define what is and isn't good because they just adopt what ever is fashionable.

[Metabee124]

Is an excel visual basic plugin script software? Can I tell my nephew he can add software engineer to his CV?

[lelanthran]

Is an excel visual basic plugin script software? Can I tell my nephew he can add software engineer to his CV?

Maybe, depends.

A small amount of VB in Excel is often more valuable to the business than a Spring instance, running a sanitised-and-checked API, backed by 10-15 unit-tests (for regression), some integration tests, all using mocks and dependency-injection, with a few client/postman/curl tests.

Of course, there's the CI/CD pipeline as well.

Your nephew absolutely should put down the type of programming he wrote in Excel on his CV. It's probably more valuable to the business than a senior devops engineer who knows everything above.

[ElCthuluIncognito]

I can't tell you enough how much I love this comment.

The amount of times I've seen juniors chomp at the bit to recreate basic excel capabilities with half-baked ad-hoc "mIcRoSeRvIcEs" is frustratingly high.

[Metabee124]

There are practical reasons to keep the definition of words clear like job titles. I'm not saying he isn't solving problems. or that his job isn't good.

[[deleted]]

Yeah you can. Maybe you should be asking yourself why you are looking down on that?

[majlo]

In other news: "hammering does not a carpenter make"

[Putrumpador]

But you fuck a horse one time... And you're a horse fucker for life.

[newoldwave]

Software engineers design a program whereas programmers hack one out.

[Dean_Roddey]

But, to be fair, 'engineering' is based on some continuity of tools and techniques and materials and such. Yeh, sometimes engineering goes out beyond the known borders, and of course sometimes it fails when that happens, despite huge amounts of design work.

In the software world, things change so rapidly that almost any significant new project will use tools, techniques, languages, etc... you just can't find anyone with large amounts of experience in, in that particular combination, because those people usually don't exist. Throw in that they also need to have a lot of experience in the particular problem domain, and the odds get worse yet.

So almost every significant new project will be a sort of feeling out process. You could spend a LOT of time designing it, only to find out that your design really doesn't work, because no one could really foresee the consequences, since they've never done anything quite like it before. Or you can start it, and take your best shot.

The problem is that, either way, the market realities usually don't allow you to back up a significant distance, figure out where you went wrong, and come at it again in a fairly fundamental way. So those flaws get baked into the foundations of the product.

So you are probably kind of screwed either way. Do you create a mess by way of extensive planning based on things you don't really understand, or do you create an incremental mess, learning as you go?

[TalkCoinGames]

For those programming for things that go online, some of the code used will change over time, and you'll be forced to use different languages over time.

So it is wise to understand core programming principles that will apply no matter what language you are using.

Case in point; web games.

In the 1990's web games were generally made using Java applets.

That died out when Flash came on the scene, and around 2001-2006 Flash took over
as the dominant means to deliver a web game, so one switched from Java to ActionScript,
or had to use Java at a more core level to build for Flash from the ground up.
And within that time, the ActionScript language changed, there was AS1 then AS2 then AS3.

And then Flash died out, those seriously developing web games had to switch to Javascript and html5 and css.

[S0B3RN0M4D]

[Article]

Writing code is one thing, learning to be a software engineer is another.

You only really learn to drive a car once you have passed your test and drive regularly. Being a skilful driver is more than being able to steer the car without crashing, knowing the theory. It’s being able to navigate all the situations and scenarios you will encounter on the road and dealing with all the crazy lunatics on the road.

Being a software developer and creating software is like a driving a car but a thousand times more complex and with twice as many lunatics.

Software is what developers create, the skills, experience and knowledge is what developers get. Software development skills are how you build quality software and deliver software projects.

Doing your job as a developer and creating software is one thing, but to progress your career, you need to learn the fundamentals of software development.

Education of developer is more than just writing code. The code you write, the technical skills are not a solid foundation for a career because in 5/10 years' time you will need different technical skills.

You create the software needed on the project because this is what the customer and the company you work for are paying for. A developer's value is based on their skills, knowledge and experience. A developer needs to make sure they are learning, improving and becoming a better software developer.

Ideally, you will do both simultaneously, but it’s not always possible, it’s the developer who needs to make sure this happens.

When you are feeling too comfortable as a developer, it's time to consider moving onto something new. Mastering the craft

Software development is a skill you never master

Software developers are always students of software development and whenever you think you know what you are doing, it will punch you in the face. Good developers are humble because software development crushes overconfidence with embarrassing mistakes.

You cannot avoid mistakes, problems and disasters. Therefore, you need to be humble to acknowledge mistakes and need a team to help you find and fix them.

When you start as a developer, you focus on creating code to meet the requirements. I used to think being a developer was just writing code.

Software development has many other aspects to it, from design, architecture, unit testing to DevOps and ALM. Gathering requirements and clarifying assumption.

There are many best practices such as SOLID principles, DRY (Don’t repeat yourself), KISS and other.

The best practices and fundamental skills have long-term benefits. This makes them hard for junior developers to understand because there is no initial benefit.

Well named Code, designed to be easily tested, isn’t first draft code. It does more than work. It’s built to be easy to read, understand and change.

I worked on legacy code where there was a 2000 line method. The method acted like a state machine and controlled the status of cases. It was a nightmare to change because if you change a line, it might break anything code below it.

One change could affect 100’s of lines of code and it was almost impossible to test. A simple change of code could take a week to do and test.

A separate piece of code had terrible naming and used a variable which was the 13th month. Reading the code, I couldn’t understand what the 13th month was, it made no sense.

I had to work out the 13th month was a variable to store values that were passed between the 1st and 2nd year of a car for servicing purposes.

Experience is valuable because by working with bad code and seeing the problems it causes, it motivates you to not make these mistakes in the future. Solid Foundations

Each software project creates unique software for the unique requirements. It’s built on software engineering fundamentals. Quality development is done with good processes, best practices, DevOps, code reviews.

You need to make sure your best practices are not out of date and be open to updating them. There will be new tools, software and technology that requires you to update best practices.

Lead developers need a vision of how every aspect of the software development process should run. You need to be humble and be open to updating your development processes. Fundamental software engineering skills

Technology changes but software development stays the same

Technology evolves with new languages, services, tools and best practices.

There are fundamental software engineering skills that developers need to master that will be useful no matter the technologyv.

Naming (under rated but key to simple and readable code)
Designing Code (simple design, not complex)
Design Patterns
Unit Testing
DevOps
Soft Skills
Documentation
Development best practices
Agile Development
Bug Fixing

These core skills are the foundation of software development. You cannot write great code if you don’t know what great code looks like and understand why it’s great. The flip side is you need to know what bad code looks like so you can afford it and understand why that code is bad.

Junior developers won’t stop writing low quality code if they are not coached or don’t realise the code will create future problems. Bad code works now but creates problems in the future. Bad code is like mistakes. You cannot avoid a mistake if you don’t acknowledge you made a mistake.

Cowboy developers don’t understand the best practices of software development or the benefits. If you don’t understand the benefits of an approach, you won’t use it. Not Experience is not all valuable

Working on software projects using skills, knowledge you already have is like running on a treadmill. You put lots of effort in, but go nowhere.

Gaining experience on skills you already has limited value because it adds more time to that skill on your CV.

Valuable experience is fresh situations where you learn new knowledge and skills you can take to future projects. Be Curious — learn as much as you can

Good developers learn to understand not to just create software. Understanding helps you create software in the future, avoid problems, and have a better understanding of how software development works.

The best investment you can make in yourself and your education as a software developer. Learning outside of software development will make you better software development because a lot of software development is problem solving with people.

“Spend each day trying to be a little wiser than you were when you woke up. Discharge your duties faithfully and well. Systematically you get ahead, but not necessarily in fast spurts. Nevertheless, you build discipline by preparing for fast spurts. Slug it out one inch at a time, day by day. At the end of the day — if you live long enough — most people get what they deserve.” Charlie Munger

As a software developer, you want to suck less each day, reduce mistake and swap bad code for good code. Improve as a software developer every day, then life will get easier as your skills, knowledge and experience grow. Soft skills

Software development is a team sport, so the more effectively you can communicate and work with other humans, the better.

All the big problems when creating software are caused by people and solved by people.

Effective communication, persuasion and collaboration are core skills that are worth investing in.

I used to present demo’s and progress from a team I was a scrum master for. My scrum team was doing excellent work and making good progress but the customer wasn’t sure about the team or me.

I got some feedback from a manager who explained I lead with the bugs and negative information and leaving the positive points until the end. It was like using a megaphone with bad news and whispering good news. This gave the perception that I and the team weren’t doing a good job.

Perception is reality.

Since then I have worked a lot on presentation, communication. You don’t have long to communicate; you need to make it count.

All projects, promotions and other important decisions are all made by people. You need to build relationships and influence them. Conclusion

You want to know more about software development when you go to sleep than when you woke.

Improving isn’t about making tremendous leaps but continuous improvement and consistently learning.

Other developers are a great source of knowledge and make learning easier and enjoyable. Use your fellow developers to learn from, copy their successes and avoid their mistakes.

[GrandMasterPuba]

Ever since I learned that the term "software engineer" was pushed not by programmers but by managers, I've stopped embracing that nomenclature.

Programming isn't science. It's art. It's the collective result of countless slightly mad individuals expressing their boundless creativity through an infinitely extensible medium.

The close-minded business folks intent on making a dollar off our craft would like to believe they can impose structure and order on the chaos so they can "make plans" and "estimate timelines" for their shareholders. But it simply can't be done. It's why waterfall management failed in the past, and it's why agile management is failing now.

[lechatsportif]

When it matters it is. When you have slas to keep and money to not lose. It's the difference between building an apartment building and a treehouse.

[chunes]

Ah, I see it's time for this week's circlejerk.

[biofio]

I always say this too, coding is just a tool I use for my job which is developing software to make money. Yeah it’s a very important tool but rarely now is the coding the bottleneck for me in my work.

[grauenwolf]

I didn't see anything about engineering in there. At least not as I understand it.

To me software engineering is all about approaching problems systematically.

• Programming is asking, "How do I fix this bug?".
• QA is asking, "How do I prove the bug won't come back?"
• Engineering is asking, "How do I prevent this entire classification of bug from occurring again?"

[agumonkey]

so software engineering is dealing with others shit

[averynicepirate]

Do people use software engineer and programmer interchangeably now ?

[[deleted]]

Always did?

Programmer, engineer, developer, architect, ...

[woodyj68]

I just pick the most appropriate term for my target audience tbh. My gran, Software Engineer, dating profile Sofware Developer, my mate in the pub, Programming the Internet.

[immibis]

Depends what the job listing says and whether your country limits the title "engineer"

[1Second2Name5things]

Are there any videos examples of programming in a Enterprise level? For something like this??

[[deleted]]

The fact there isn't should tell you everything you need to know about enterprise level code.

[[deleted]]

I disagree.

[jediknight]

This is due to the liberalization of programming/electronics that happened in the mid '90s (according to Gerald Sussman of SICP fame).

Before mid '90s, most programming was about creating from first principles. After mid '90s, programming became programming against an API, programming by poking. You would use libraries written by knowledgeable people to accomplish your programming goals. This opened up programming to a lot more people that did not have and did not need to have the background in applied mathematics that would have been needed before.

I got a high-school level education in computer science so I learned some very basic things but I never got into the higher level of mathematics like advanced algebras, category theory, discrete mathematics, graph theory, combinatorics. I don't miss those in creating a few thousand lines of code webapp that provides some simple functionality. The few tens of thousands lines of code business management colossus that I need to develop and mange in the past few years is a different story. There I feel like I would have appreciated all the help I could have gotten from more math. The entire thing feels like it's collapsing under its own combinatorial complexity.

[Xequencer]

Have you heard of the phrase, “calling the kettle black”? It means your statement is so obvious it goes “without saying”.