6 ms·

It still is engineering you only mistake design phase. Writing code is the design phase. You don’t need design phase for doing design. Will drop link to rele

• ozim 1y ago
  This is the talk on real software engineering: https://www.youtube.com/watch?v=RhdlBHHimeM https://www.youtube.com/watch?v=RhdlBHHimeM
• jmholla 1y ago
  I also read this series of blog posts recently where the author, Hillel Wayne, talked to several "traditional" engineers that had made the switch to software. He came to a similar conclusion and while I was previously on the fence of how much of what software developers do could be considered engineering, it convinced me that software engineer is a valid title and that what we do is engineering. First post here: https://www.hillelwayne.com/post/are-we-really-engineers/ https://www.hillelwayne.com/post/are-we-really-engineers/
  • 3036e4 1y ago
    I was an undergraduate (computer) engineer student, but like many of my friends at that time (dot-com boom) I did not graduate since it was too tempting to get a job and get well paid instead. However many, probably half, that I work with, and most that I worked with overall for the last 25+ years (since after I dropped out) have an engineering degree. Especially the younger ones, since this century it has been more focus on getting a degree and fewer seems to drop out early to get a job like many of us did in my days. So when American employers insist on giving me titles like "software engineer" I cringe. It's embarrassing really, since I am surrounded by so many that have a real engineering degree, and I don't. It's like if I dropped out of medical school and then people started calling me "doctor" even if I wasn't one, legally. It would be amazing if we could find a better word so that non-engineers like me are not confused with the legally real engineers.
    • AndrewDavis 1y ago
      I've decided that titles are mostly meaningless in software. What X title means in one org means another in a different one with near zero overlap, and another title might have considerable overlap with a differently named one but viewed lowly, borderline pejoratively at another org. Eg system admin vs devops vs sre. In one org sysadmins are deploying desktop machines with no expectations they can cut code, in my old role as one I was working with Linux systems, building glue and orchestration, and when things go wrong debugging backend code written by a development team. Something far closer to the work of "devops" or "sre". As a aside, I find your example of doctor as amusing because it's overloaded with many considering the term a synonym of physician, and the confusion that can cause with other types of doctors.
    • lukan 1y ago
      If you are doing the work of an engineer and you do it right, I believe you are an engineer, whether you graduated, or not. And proper software developement definitely has engineering parts. Otherwise titles are just labels.
  • wolvesechoes 1y ago
    Personally I don't need to talk with "traditional" engineers to have an opinion there, as I am mechanical engineer that currently deals mostly with software, but still in the context of "traditional" engineering (models and simulation, controls design). Definitely making software can be engineering, most of the time it is not, not because of the nature of software, but the characteristics of the industry and culture that surrounds it, and argument in this article is not convincing (15 not very random engineers is not that much to support the argument from "family resemblance").
    • gabrielpoca118 1y ago
      But what about other engineering fields? From what I understand, if you compare it to chemical engineering, you have many more similarities, because you’re doing Hypothesis -> Experiment -> Analyze -> Refine -> Repeat, which seems very similar to what we do in software
      • wolvesechoes 1y ago
        Mechanical engineering also uses prototypes, iteration, lab testing etc. Building architects build multiple models before the first shovel is put into the ground. Software is clearly different than "hardware", but it doesn't mean that other industries do not use experiment and iteration.
        • gabrielpoca118 1y ago
          ok you lost me then xD I was trying to understand what you meant by it not being engineering most of the time.
          • ozim 1y ago
            I will add this link once more. This is the talk on real software engineering: https://www.youtube.com/watch?v=RhdlBHHimeM https://www.youtube.com/watch?v=RhdlBHHimeM
    • 1y ago
• erichocean 1y ago
  > Writing code is the design phase. Rich Hickey agrees it's a part of it, yes. https://www.youtube.com/watch?v=c5QF2HjHLSE https://www.youtube.com/watch?v=c5QF2HjHLSE
• motorest 1y ago
  > Writing code is the design phase. No, it really isn't. I don't know which amateur operation you've been involved with, but that is really not how things work in the real world. In companies that are not entirely dysfunctional, each significant change to the system's involve a design phase, which often includes reviews from stakeholders and involved parties such as security reviews and data protection reviews. These tend to happen before any code is even written. This doesn't rule out spikes, but their role is to verify and validate requirements and approaches, and allow new requirements to emerge to provide feedback to the actual design process. The only place where cowboy coding has a place is in small refactoring, features and code fixes.
  • mytailorisrich 1y ago
    It is, as often, a trade-off. You need a high level design up-front but it should not be set in stone. Writing code and iterating is how you learn and get to a good, working design. Heavy design specs up-front are a waste of time. Hence, the agile manifesto's "Working software over comprehensive documentation", unfortunately the key qualifier "comprehensive" is often lost along the way... On the whole I agree that writing code is the design phase. Software dev. is design and test.
    • motorest 1y ago
      > You need a high level design up-front but it should not be cast in stone. Yes, you need a design that precedes code. > Writing code and iterating is how you learn and get to a good, working design. You are confusing waterfall-y "big design upfront" with having a design. It isn't. This isn't even the case in hard engineering fields such as aerospace where prototypes are used to iterate over design. In software engineering fields you start with a design and you implement it. As software is soft, you do not need to pay the cost of a big design upfront.
      • mytailorisrich 1y ago
        > You are confusing waterfall-y "big design upfront" with having a design. I do not and I have explained it. > In software engineering fields you start with a design and you implement it And part of my previous comment is that this "waterfall-y" approach in which you design first and implement second does not work and has never worked. > you do not need to pay the cost of a big design upfront Exactly, and not only that but usually requirements will also change along the way. The design can change and will change as you hit reality and learn while writing actual, working code. So keep your design as a high-level initial architecture then quickly iterate by writing code to flesh out the design. Software is often opposed to "traditional engineering" but it is actually the same. How many experiments, prototyopes, iterations go into building a car or a rocket? Many. Engineers do not come up with the final design up front. The difference it is that this is expensive while in software we can iterate much more, much quicker, and for free to get to the final product.
• ChrisMarshallNY 1y ago
  I see there has been a “spirited discussion” on this. We can get fairly emotionally invested into our approaches. In my experience (and I have quite a bit of it, in some fairly significant contexts), “It Depends” is really where it’s at. I’ve learned to take an “heuristic” approach to software development. I think of what I do as “engineering,” but not because of particular practices or educational credentials. Rather, it has to do with the Discipline and Structure of my approach, and a laser focus on the end result. I have learned that things don’t have to be “set in stone,” but can be flexed and reshaped, to fit a particular context and development goal, and that goals can shift, as the project progresses. When I have worked in large, multidisciplinary teams (like supporting hardware platforms), the project often looked a lot more “waterfall,” than when I have worked in very small teams (or alone), on pure software products. I’ve also seen small projects killed by overstructure, and large projects, killed, by too much flexibility. I’ve learned to be very skeptical of “hard and fast” rules that are applied everywhere. Nowadays, I tend to work alone, or on small teams, achieving modest goals. My work is very flexible, and I often start coding early, with an extremely vague upfront design. Having something on the breadboard can make all the difference. I’ve learned that everything that I write down, “ossifies” the process (which isn’t always a bad thing), so I avoid writing stuff down, if possible. It still needs to be tracked, though, so the structure of my code becomes the record. Communication overhead is a big deal. Everything I have to tell someone else, or that they need to tell me, adds rigidity and overhead. In many cases, it can’t be avoided, but we can figure out ways to reduce the burden of this crucial component. It’s complicated, but then, if it were easy, everyone would be doing it.
• marcyb5st 1y ago
  Googler, but opinions are my own. I disagree. The design phase of a substantial change should be done beforehand with the help of a design doc. That forces you to put in writing (and in a way that is understandable by others) what you are envisioning. This exercise is really helpful in forcing you to think about alternatives, pitfalls, pros & cons, ... . This way, once stakeholders (your TL, other team members) agreed then the reviews related to that change become only code related (style, use this standard library function that does it, ... ) but the core idea is there.
  • ozim 1y ago
    This is the talk I mentioned in my original comment: https://www.youtube.com/watch?v=RhdlBHHimeM https://www.youtube.com/watch?v=RhdlBHHimeM
  • mytailorisrich 1y ago
    This should only be a first phase of the design and should be high level and not a commitment. Then you quickly move on to iterate on this by writing working code, this is also part of the design. Having an initial design approved and set in stone, and then a purely implementation phase is very waterfall and very rarely works well. Even just "pitfalls and pros & cons" are hard to get right because what you thought was needed or would be a problem may well turn out differently when you get hands-on and have actual data in the form of working code.