My ideal position would be designing systems and programs, I love the industry and the technology but I just don't really like ONLY coding.
People at my work say that nowadays you can't just be a software architect.
Any insight?
NOTE: I didn't say I don't like coding, I meant I don't like ONLY coding (see edit above).
You can be, so long as you like very large projects and have many years of experience in development or closely related roles. It would be hard to design something without a fair bit of experience in building it.
I have been in the position of software architect on several projects for the last ten years or so. Team sizes have varied (initially 3-4 programmers, now 15-20). In every role, I ensured that I would be building at least part of the system. I've found that an architect who isn't also coding is in very real danger of getting out of touch, and so it's critical to keep my hands dirty.
So, the answer is yes, being a software architect does not mean that you are prevented from doing low-level work at the same time. You've just got to design your role to make sure that coding remains a part of it.
I've found that doing things this way gives me the best of both worlds: I get to do the higher-level work of system design, while still doing enough coding to scratch that itch as well. It's a great mix if you can arrange it!
I'm not sure what people mean by "you can't just be a software architect." There are plenty of people who are just software architects. To be a successful architect you still need to be able to code and code well. Typically the architects have the most experience with a variety of technologies and have the experience to build out the high level design. If you are not qualified to be an architect I would recommend you consider a type of consulting job. A lot of consultant positions can participate in all levels of the SDLC (Software Development Life Cycle), and some of them require you to do it all.
As long as you still understand coding, I think you could be a good architect. I don't like figuring out my taxes at the end of the year, but I still know how to do it.
As for the naysayers at your current job, maybe it is just the specific business you are in. There are plenty of areas that architects are still useful.
I don't want to be rude, but gee, probably is my lack experience in english, but here I go.
Blockquote
People at my work say that nowadays you can't just be a software architect.
Blockquote
Probably that what they say to "you". To be an architect you need a lot of experience and nothing better to get it than coding. You may become an "in paper architect" but your designs will have flaws.
Of course you can be architect only ( and earn a lot more ) , but it will be hard to start as one.
Peace.
You have to be a pretty good coder to be a good architect. I don't see how you can become a good coder unless you love it.
I'm an architect and I can say you need to be an excellent coder. But you must be able to "see the bigger picture" -- and to understand technology and how that technology solves real business problems and throw away or discount those that do not. If, as you say, you don't just solely enjoy coding its probably the route for you.
You couldn't design a car without knowing its inner workings... nor could you design a house without understanding the limitations of the tools that the construction workers will eventually be using to build it. Similarly, how could you hope to design software without knowing the technical details that comprise the act of programming it?
I think the software architect is a mythical beast from Ye Olde Times. I've yet to see one.
In my company the "project manager" role is nearly always a software architect type position. This person writes some code, but spends more of their time coordinating developer activities and working with (internal) customers on design-level issues
As an architect, I am still doing a lot of coding - prototyping, improving the existing solutions and troubleshooting.
There are many flavours of Architect - I'd like to think that they exhibit one or more of the following characteristics:
Pick two or more traits and you have the making of an Architect role. As an IC Architect for the last 10 years, it is my firm belief that being able to code is critical to your success at influencing others.
I don't like to be negative, but I personally have very little respect for "architects" who are not actively involved in the coding. It's very easy to draw a bunch of box-and-line diagrams and whip up some UML to create a "design" that is garbage, and then blame the lowly coders for whatever problems they have during implementation.
An architect who doesn't code is no different from a marketing person who makes promises to customers without any clue as to how those promises can be kept.
I think a lot of it has to do with how large your development organization is. I'd imagine that Microsoft, for example, has architects who do little or no coding, but in my 8 person development organization, being an architect mostly means that I am capable of wearing any hat that's needed: product manager, designer, developer, coordinator, referee, tech support...the list is endless. The higher you climb on the org chart, the more that you're expected to be able to handle, but it doesn't always guarantee that you'll drop all of your old responsibilities.
That said, it's hard for me to imagine being a good architect without having a passion for software development. You may grow out of doing day-to-day grunt work, but "I just don't really like just coding" sounds a little problematic.
In order to be an architect, you have to know what can be built and how. More often than not you need to demonstrate what can be built as well.
If you can't do this, or (and this happens) you've been doing architecture instead of development for so long that you're out of touch with current practices and techniques, you're not going to be a very effective architect.
As the joke goes:
Q. How many architects does it take to screw in a light bulb?
A. That's an implementation detail.
Doing all the design work and expecting others to do the implementation is unrealistic. I'm sure you can do it, but you'll get bad software out of it.
It goes both ways. You cannot design things without building them and you cannot build things without designing them. Building good software is an iterative process. Your first design will be bad and you won't realize how bad it is until you try to implement it.
Also, do you really want to design the system and then hand off the implementation to someone who isn't a good enough programmer to have been able to design it themselves? I hope not.