6 ms·

Honestly, it sounds like you may be geared more towards software architecture rather than software development. If you like the sound of the bigger picture more

Honestly, it sounds like you may be geared more towards software architecture rather than software development. If you like the sound of the bigger picture more than the details, it might be something you could look into.

SamReidHughes 8y ago
If you can't handle simple data structures problems you need to stay far, far away from software architecture.
- scarface74 8y ago
  In the real world software architecture is rarely about “data structures”. Software architecture is about teasing out the needs of the customer - whether that be internal or external - and knowing how to design systems that are maintainable, scalable, fault tolerant, etc.
  - SamReidHughes 8y ago
    Scalable, fault tolerant systems is a distributed systems problem, which is a harder form of data structures problem.
    - scarface74 8y ago
      Yes but unless you are actually working on creating the system that other people implement, you are just using work made by others. You don’t need to know the ins and outs of various gossip protocols.
  - rapind 8y ago
    Potentially two things here: 1) Gathering requirements. 2) Turning those requirements into data structures. I think a lot of companies will separate those into different roles, but I strongly believe that's a costly mistake in most situations. There's a feedback loop. Requirements inform your data structures, but your data structures help you contextualize (not pollute) your requirements. If you're working with an existing system, you also want to understand current structures in order to guide requirements. By guide, I don't mean to ignore pain, but if you're building a system to support multiple clients / users, then the real trick is to figure out how to do that in a cost-effective and elegant way. When these roles are separated, and the requirements are gathered without knowledge of the structures, I believe you're setting yourself for failure in the long term (spaghetti code / everyone gets something different). Getting these to gel is the puzzle I'm personally passionate about. I don't mind what I would call the math side of programming / code puzzles, but it simply doesn't give me the endorphin rush that building a system that elegantly ties things together does. The best is when you're working towards that or have achieved that and inspiration for further possibilities, improvements, efficiencies start popping up. I'm not sure how you test for this as part of the hiring process, at least not efficiently. I do think we get better at this with experience, but I doubt it's exclusive to seasoned developers.
    - scarface74 8y ago
      But still “data structures” in the context of most businesses are more Domain Driven Design “Domain Contexts”, “Aggregate Roots”, type structures than any type of complicated CS type data structures.
- theoh 8y ago
  That depends on what is meant by software architecture. If you mean the structuring of a system to achieve good or (particularly) consistent worst-case performance, maybe you are right. But if architecture is used to mean the design of a system to satisfy users (and present a clean, extensible, meaningful interface) then it's really a conceptual job that has more to do with design skills than optimized algorithms.
  - SamReidHughes 8y ago
    Being able to make a clean interface, as in a clean API, or useful one, is a data structures/algorithms problem and often a distributed systems problem. Many API's are technically impossible to use correctly. For example they might not let you do two things atomically that need to be. Or they might suffer enormously because they don't version their information properly, resulting in client/server disagreements over the nature of reality that are impossible to avoid. Or you get components that are impossible to interrupt cleanly or shut down safely. It's not the same thing as some piddly twenty minute problem -- it's harder, requires some experience, and it has the same kind of aptitude. Consider it a rule that people that can't handle data structures problems are going to create systems architecture problems.
    - theoh 8y ago
      Designing something on an architectural level really isn't always a data structures and algorithms problem. Take the web, for example. REST isn't complicated, but it does the job and it opened up more possibilities than any other invention since timesharing. As other commenters have noted, choosing an architecture for a system may have more to do with vision, common sense, and even imagination. And the web is such a great example of this, maybe the classic example. As you probably know, it's possible to write a webserver without having a clue about fancy data structures or algorithms. It's the imaginative composition of pre-existing features that creates the architecture. Another example would be the extensibility of Emacs through elisp. Consider the notion of hooks which essentially allow utility functions to be customized by the user. It's a purely architectural concept. Or the Unix philosophy: small utilities that read and write text, linked by pipes. Really no algorithmic complexity to it at all. It feels problematic to me that you are saying to someone that they "need to stay far, far away" from some aspect of computing. It's a kind of gatekeeping. Sure, an outfit like NASA needs to make sure that they don't have amateurs writing their systems software. But in the industry more broadly, people have to be given permission to pursue whatever interests them. It's important, for diversity and the invention of new applications, that "differently able" coders aren't told, by intimidating stereotypical computer science types, that they don't have the aptitude to architect a useful system, or that it's "a rule" that people with their skills will just create problems. Vision and a perspective that differs from the norm are a lot rarer and potentially more valuable than the ability to apply software engineering principles. Architecture, in the broadest sense, is precisely the area where these "outside the box" contributions are likely to be valuable. Consider the invention of the Wiki. It came out of the pattern language world, it was a hugely beneficial innovation, and it has almost zero data structures/algorithms complexity behind it. I'd even argue that the examples of pitfalls that you list are more clerical matters of systems programming than cases where architectural design principles are lacking. (And even the professionals who can reliably grind out working code for large systems can get the architecture spectacularly wrong, as the case of the X window system: http://web.archive.org/web/20170920104011/https://minnie.tuhs.org//pipermail/tuhs/2017-September/010471.html http://web.archive.org/web/20170920104011/https://minnie.tuh... )
- sn41 8y ago
  Not really, not at all. Software architecture is a lot about wisdom - how to anticipate future changes. Often user interfaces need to be carefully and gently designed so that the user has no surprises. Diligence from the user should not be assumed, the user interface must emphasize tricky parts and make choices less onerous, etc. Scalability is preferrably achieved by simple code + hardware/vms rather than overoptimized code which depends on "irreplaceable" programmers - what if they fall sick, or leave the company? etc. I think all of this is experience accrued over many years, and with facing many failures. I have found that the data structures that you need are often simple trees and hashes. Database design is probably more important. I often shake my head at students doing hours of dynamic programming to crack interviews. In the past year, how many problems in your company have you solved through dynamic programming? I suspect, not many.
- nailer 8y ago
  Parent was discussing not being interested in algo design, rather than not knowing data structures.
opportune 8y ago
Is it possible to even get into software architecture without pretty significant experience? From my experience in the workplace anybody making purely architectural decisions without having to implement them is a team lead or higher in the organizational architecture.
- notyourwork 8y ago
  Which makes sense right? Same reason a military general doesn’t start as a general. Architecture takes experience in the weeds to give a breadth you can leverage as you reason through architecture. Architecture isn’t aslways black and white decision making based on some specs which is where experience can help a ton.
  - Aeolun 8y ago
    Generals often start out as lieutenants though (e.g. officer academy drops you in on a higher rank).
    - skh 8y ago
      In the U.S. military this is not true. People graduating from OCS, ROTC, or one of the academies start off at O-1 (2nd Lieutenant).
      - learc83 8y ago
        What's your disagreement? 1st Lieutenant vs 2nd Lieutenant? Lieutenant is commonly used to refer to both. Or are you saying that you start of at O-1 and not a higher paygrade? If that's the case, the OP was pointing out that you start off outranking enlisted service members, not that you start out above O-1.
        skh 8y ago
        Well, I misread the comment I responded to. I thought they said that academy graduates don’t start off at lieutenant and start off at a higher rate.
nicoburns 8y ago
I like roles where I get to do both! I've found that a lot of problems come from these being different roles, and the developers not really understanding or buying into the vision of the architects (who might be able to see the big picture, but can often make decisions that make no sense due to being removed from the details of the existing implementation). Of course in really large companies I suppose having these as a seperate role is a necessary evil. But I still think there should be much more collaboration and interaction between people in these different roles than I generally see.
paulgrant999 8y ago
my understanding is with the migration to thousands of "pizza" developer teams doing self-service, that "no one person understand the entire codebase" i.e. software architecting is dead. Am I in error to hold this belief?

SamReidHughes 8y ago

If you can't handle simple data structures problems you need to stay far, far away from software architecture.

scarface74 8y ago
In the real world software architecture is rarely about “data structures”. Software architecture is about teasing out the needs of the customer - whether that be internal or external - and knowing how to design systems that are maintainable, scalable, fault tolerant, etc.
- SamReidHughes 8y ago
  Scalable, fault tolerant systems is a distributed systems problem, which is a harder form of data structures problem.
  - scarface74 8y ago
    Yes but unless you are actually working on creating the system that other people implement, you are just using work made by others. You don’t need to know the ins and outs of various gossip protocols.
- rapind 8y ago
  Potentially two things here: 1) Gathering requirements. 2) Turning those requirements into data structures. I think a lot of companies will separate those into different roles, but I strongly believe that's a costly mistake in most situations. There's a feedback loop. Requirements inform your data structures, but your data structures help you contextualize (not pollute) your requirements. If you're working with an existing system, you also want to understand current structures in order to guide requirements. By guide, I don't mean to ignore pain, but if you're building a system to support multiple clients / users, then the real trick is to figure out how to do that in a cost-effective and elegant way. When these roles are separated, and the requirements are gathered without knowledge of the structures, I believe you're setting yourself for failure in the long term (spaghetti code / everyone gets something different). Getting these to gel is the puzzle I'm personally passionate about. I don't mind what I would call the math side of programming / code puzzles, but it simply doesn't give me the endorphin rush that building a system that elegantly ties things together does. The best is when you're working towards that or have achieved that and inspiration for further possibilities, improvements, efficiencies start popping up. I'm not sure how you test for this as part of the hiring process, at least not efficiently. I do think we get better at this with experience, but I doubt it's exclusive to seasoned developers.
  - scarface74 8y ago
    But still “data structures” in the context of most businesses are more Domain Driven Design “Domain Contexts”, “Aggregate Roots”, type structures than any type of complicated CS type data structures.
theoh 8y ago
That depends on what is meant by software architecture. If you mean the structuring of a system to achieve good or (particularly) consistent worst-case performance, maybe you are right. But if architecture is used to mean the design of a system to satisfy users (and present a clean, extensible, meaningful interface) then it's really a conceptual job that has more to do with design skills than optimized algorithms.
- SamReidHughes 8y ago
  Being able to make a clean interface, as in a clean API, or useful one, is a data structures/algorithms problem and often a distributed systems problem. Many API's are technically impossible to use correctly. For example they might not let you do two things atomically that need to be. Or they might suffer enormously because they don't version their information properly, resulting in client/server disagreements over the nature of reality that are impossible to avoid. Or you get components that are impossible to interrupt cleanly or shut down safely. It's not the same thing as some piddly twenty minute problem -- it's harder, requires some experience, and it has the same kind of aptitude. Consider it a rule that people that can't handle data structures problems are going to create systems architecture problems.
  - theoh 8y ago
    Designing something on an architectural level really isn't always a data structures and algorithms problem. Take the web, for example. REST isn't complicated, but it does the job and it opened up more possibilities than any other invention since timesharing. As other commenters have noted, choosing an architecture for a system may have more to do with vision, common sense, and even imagination. And the web is such a great example of this, maybe the classic example. As you probably know, it's possible to write a webserver without having a clue about fancy data structures or algorithms. It's the imaginative composition of pre-existing features that creates the architecture. Another example would be the extensibility of Emacs through elisp. Consider the notion of hooks which essentially allow utility functions to be customized by the user. It's a purely architectural concept. Or the Unix philosophy: small utilities that read and write text, linked by pipes. Really no algorithmic complexity to it at all. It feels problematic to me that you are saying to someone that they "need to stay far, far away" from some aspect of computing. It's a kind of gatekeeping. Sure, an outfit like NASA needs to make sure that they don't have amateurs writing their systems software. But in the industry more broadly, people have to be given permission to pursue whatever interests them. It's important, for diversity and the invention of new applications, that "differently able" coders aren't told, by intimidating stereotypical computer science types, that they don't have the aptitude to architect a useful system, or that it's "a rule" that people with their skills will just create problems. Vision and a perspective that differs from the norm are a lot rarer and potentially more valuable than the ability to apply software engineering principles. Architecture, in the broadest sense, is precisely the area where these "outside the box" contributions are likely to be valuable. Consider the invention of the Wiki. It came out of the pattern language world, it was a hugely beneficial innovation, and it has almost zero data structures/algorithms complexity behind it. I'd even argue that the examples of pitfalls that you list are more clerical matters of systems programming than cases where architectural design principles are lacking. (And even the professionals who can reliably grind out working code for large systems can get the architecture spectacularly wrong, as the case of the X window system: http://web.archive.org/web/20170920104011/https://minnie.tuhs.org//pipermail/tuhs/2017-September/010471.html http://web.archive.org/web/20170920104011/https://minnie.tuh... )
sn41 8y ago
Not really, not at all. Software architecture is a lot about wisdom - how to anticipate future changes. Often user interfaces need to be carefully and gently designed so that the user has no surprises. Diligence from the user should not be assumed, the user interface must emphasize tricky parts and make choices less onerous, etc. Scalability is preferrably achieved by simple code + hardware/vms rather than overoptimized code which depends on "irreplaceable" programmers - what if they fall sick, or leave the company? etc. I think all of this is experience accrued over many years, and with facing many failures. I have found that the data structures that you need are often simple trees and hashes. Database design is probably more important. I often shake my head at students doing hours of dynamic programming to crack interviews. In the past year, how many problems in your company have you solved through dynamic programming? I suspect, not many.
nailer 8y ago
Parent was discussing not being interested in algo design, rather than not knowing data structures.

opportune 8y ago

Is it possible to even get into software architecture without pretty significant experience? From my experience in the workplace anybody making purely architectural decisions without having to implement them is a team lead or higher in the organizational architecture.

notyourwork 8y ago
Which makes sense right? Same reason a military general doesn’t start as a general. Architecture takes experience in the weeds to give a breadth you can leverage as you reason through architecture. Architecture isn’t aslways black and white decision making based on some specs which is where experience can help a ton.
- Aeolun 8y ago
  Generals often start out as lieutenants though (e.g. officer academy drops you in on a higher rank).
  - skh 8y ago
    In the U.S. military this is not true. People graduating from OCS, ROTC, or one of the academies start off at O-1 (2nd Lieutenant).
    - learc83 8y ago
      What's your disagreement? 1st Lieutenant vs 2nd Lieutenant? Lieutenant is commonly used to refer to both. Or are you saying that you start of at O-1 and not a higher paygrade? If that's the case, the OP was pointing out that you start off outranking enlisted service members, not that you start out above O-1.
      - skh 8y ago
        Well, I misread the comment I responded to. I thought they said that academy graduates don’t start off at lieutenant and start off at a higher rate.

nicoburns 8y ago

I like roles where I get to do both! I've found that a lot of problems come from these being different roles, and the developers not really understanding or buying into the vision of the architects (who might be able to see the big picture, but can often make decisions that make no sense due to being removed from the details of the existing implementation). Of course in really large companies I suppose having these as a seperate role is a necessary evil. But I still think there should be much more collaboration and interaction between people in these different roles than I generally see.

paulgrant999 8y ago

my understanding is with the migration to thousands of "pizza" developer teams doing self-service, that "no one person understand the entire codebase" i.e. software architecting is dead. Am I in error to hold this belief?