5 ms·

“Software engineering” in practice is 90% about keeping your stuff organized well enough that you and others can comprehend it, make sure it does what it intend

“Software engineering” in practice is 90% about keeping your stuff organized well enough that you and others can comprehend it, make sure it does what it intends, and use and and extend it. That extends to making project plans to begin with, and any documentation. That’s hard to teach as a separate thing.

ThePadawan 6y ago
I took a course in Software Engineering as part of my CS degree. As part of that course, we simulated spec work by having Team A write the specifications for a project and having Team B trying to interpret that as loosely as possible while still being compliant. (Team C would then do that with Team B's spec and so on, so there would be no 'revenge'). That wasn't perfect, but it did teach us a lot about writing down implicit and non-functional requirements, as well as the use of precise language.
- to11mtm 6y ago
  When I did CS (my alma mater didn't have Software engineering at the time,) many courses did similar but with a different spin; The work based on the exercise was pre-divided into modules that were fairly similar in size. And at the end you had to code your module and everything had to 'work together'. As a blunt observation, the courses where writing a specification was part of the project everything seemed to click together more easily. The ones where a specification wasn't written were the ones where people were scrambling on due date.
Ultimatt 6y ago
That's the 10%. 90% is working out what to even do, and managing all the humanity in the system before you arrived to build software.
whatever1 6y ago
As a non-CS engineer who writes software for a living, I can definitely say that there are times that I wish I had formal training in algorithms, parallel data structures, compilers, operating systems and hardware. There are many times that I need to rewrite my code because of non-adequate design. Other times I reach corner cases that take me too long to debug, only to realize much later that there was a lower-level explanation for the unexpected behavior.
- mannykannot 6y ago
  Congratulations! By not dismissing these temporary setbacks as being just the way things are, you have the right attitude to become even more successful at what you do. There seems to be lots of information, of the sort you are interested in, available on the internet (I won't recommend anything specific as there is too much!) One can learn a lot simply by digging deeper into the specific issues that one has encountered, especially as you begin to see the links between them.
  - mistersquid 6y ago
    > There seems to be lots of information, of the sort you are interested in, available on the internet (I won't recommend anything specific as there is too much!) As a non-CS developer, I find this us not an easy problem to overcome: the wide availability of resources of varying quality. I work more than full time (US exempt employee), and I have enough knowledge that intermediate depth and quality resources do not provide enough and, not having a solid grasp of fundamentals, MIT's SICP course is a bit beyond my current grasp, I would love recommendations for a series of courses, a series of syllabuses, or even a part-time degree program where I could meaningfully progress while working full time. I'm not afraid of advanced math, I'm ignorant but willing to learn about data structures. I'm highly educable but I'm time-poor. What targeted resources would be a good investment of my limited time?
- AnHonestComment 6y ago
  My “one weird trick” is take the time to understand type theory. How are types implemented? What are the native types on your computer? How do types and whiteboard diagrams relate? If you can answer those questions, you’ll start to get an intuitive sense of how to make a program out of types (eg, domain driven design) and of how the computer will interpret those types.
- swat535 6y ago
  I graduated with a CS degree and a minor in Web Services and Applications. Let me tell you that whilst those topics are useful, they were pretty tailored and if I'm being 100% honest, I don't even recall the majority of them. My day to day job is piping APIs together and making sure we deliver features on time. On the rare occasion that I need to use a data structure or an algorithm to optimize for Time Space complexity, I'll either use a community built package or a language level feature. I'll never invent my own because whatever I come up with will be half baked anyway. Knowing all the above is useful for passing interviews but not much use in your everyday life unless you are doing something other than SWE such as R&D or data science. Just my 2c.
chrismeller 6y ago
That’s funny. I completely agree, but at work lately I’ve come up against a religious fanaticism level of DRY and “we created an algorithm to match all these things”. Great, you spent two weeks saving two percent of compute time and now only two people will ever be able to change this code. WTF?
dj_mc_merlin 6y ago
That is a perspective one acquires after a while. Another huge part is having the knowledge required to not blunder. The questions a beginner SE might ask are along the lines of "what are pipes? how do you package something to release it? how do I revert a git commit? how do i exit vim?". I know many people who are completing degrees in CS and related fields that do not know the answer to these questions. That said, I think the best way to learn these kind of things is on the job, if you find a company kind enough to let you practice the basics.
- x86ARMsRace 6y ago
  I'd say it's less to do with kindness and more along the lines of a VC who invests in a hand full of startups. If you train a certain amount of beginners, you'll likely turn out a few high value engineers. A few really strong engineers could produce sufficient business value that they offset the 'loss' for the ones that don't really make the cut.
  - imtringued 6y ago
    Abandoning businesses is fine, abandoning people can be cruel.

ThePadawan 6y ago

I took a course in Software Engineering as part of my CS degree. As part of that course, we simulated spec work by having Team A write the specifications for a project and having Team B trying to interpret that as loosely as possible while still being compliant. (Team C would then do that with Team B's spec and so on, so there would be no 'revenge'). That wasn't perfect, but it did teach us a lot about writing down implicit and non-functional requirements, as well as the use of precise language.

to11mtm 6y ago
When I did CS (my alma mater didn't have Software engineering at the time,) many courses did similar but with a different spin; The work based on the exercise was pre-divided into modules that were fairly similar in size. And at the end you had to code your module and everything had to 'work together'. As a blunt observation, the courses where writing a specification was part of the project everything seemed to click together more easily. The ones where a specification wasn't written were the ones where people were scrambling on due date.

Ultimatt 6y ago

That's the 10%. 90% is working out what to even do, and managing all the humanity in the system before you arrived to build software.

whatever1 6y ago

As a non-CS engineer who writes software for a living, I can definitely say that there are times that I wish I had formal training in algorithms, parallel data structures, compilers, operating systems and hardware. There are many times that I need to rewrite my code because of non-adequate design. Other times I reach corner cases that take me too long to debug, only to realize much later that there was a lower-level explanation for the unexpected behavior.

mannykannot 6y ago
Congratulations! By not dismissing these temporary setbacks as being just the way things are, you have the right attitude to become even more successful at what you do. There seems to be lots of information, of the sort you are interested in, available on the internet (I won't recommend anything specific as there is too much!) One can learn a lot simply by digging deeper into the specific issues that one has encountered, especially as you begin to see the links between them.
- mistersquid 6y ago
  > There seems to be lots of information, of the sort you are interested in, available on the internet (I won't recommend anything specific as there is too much!) As a non-CS developer, I find this us not an easy problem to overcome: the wide availability of resources of varying quality. I work more than full time (US exempt employee), and I have enough knowledge that intermediate depth and quality resources do not provide enough and, not having a solid grasp of fundamentals, MIT's SICP course is a bit beyond my current grasp, I would love recommendations for a series of courses, a series of syllabuses, or even a part-time degree program where I could meaningfully progress while working full time. I'm not afraid of advanced math, I'm ignorant but willing to learn about data structures. I'm highly educable but I'm time-poor. What targeted resources would be a good investment of my limited time?
AnHonestComment 6y ago
My “one weird trick” is take the time to understand type theory. How are types implemented? What are the native types on your computer? How do types and whiteboard diagrams relate? If you can answer those questions, you’ll start to get an intuitive sense of how to make a program out of types (eg, domain driven design) and of how the computer will interpret those types.
swat535 6y ago
I graduated with a CS degree and a minor in Web Services and Applications. Let me tell you that whilst those topics are useful, they were pretty tailored and if I'm being 100% honest, I don't even recall the majority of them. My day to day job is piping APIs together and making sure we deliver features on time. On the rare occasion that I need to use a data structure or an algorithm to optimize for Time Space complexity, I'll either use a community built package or a language level feature. I'll never invent my own because whatever I come up with will be half baked anyway. Knowing all the above is useful for passing interviews but not much use in your everyday life unless you are doing something other than SWE such as R&D or data science. Just my 2c.

chrismeller 6y ago

That’s funny. I completely agree, but at work lately I’ve come up against a religious fanaticism level of DRY and “we created an algorithm to match all these things”. Great, you spent two weeks saving two percent of compute time and now only two people will ever be able to change this code. WTF?

dj_mc_merlin 6y ago

That is a perspective one acquires after a while. Another huge part is having the knowledge required to not blunder. The questions a beginner SE might ask are along the lines of "what are pipes? how do you package something to release it? how do I revert a git commit? how do i exit vim?". I know many people who are completing degrees in CS and related fields that do not know the answer to these questions. That said, I think the best way to learn these kind of things is on the job, if you find a company kind enough to let you practice the basics.

x86ARMsRace 6y ago
I'd say it's less to do with kindness and more along the lines of a VC who invests in a hand full of startups. If you train a certain amount of beginners, you'll likely turn out a few high value engineers. A few really strong engineers could produce sufficient business value that they offset the 'loss' for the ones that don't really make the cut.
- imtringued 6y ago
  Abandoning businesses is fine, abandoning people can be cruel.