Jim Carnicelli - Full-stack developer
What does that mean?
A full-stack developer has the skills necessary to do all these development tasks.
A broader interpretation of "full-stack developer" could be synonymous with "software engineer" and imply that such a person can design, implement, and maintain entire projects. These people will be comfortable with roles of project manager, business analyst, technical designer, coder, tester, documenter, maintainer, database designer, database administrator, and so on.
I've served every basic role in the software development life-cycle. I describe myself as a software engineer, but also as a full-stack developer. I can take on all the essential roles and design and implement all the layers of a typical business application. I have worked on teams of all sizes for companies of all sizes. I have done entire enterprise systems by myself and with small teams assisting me. I have been project manager and chief architect for larger teams repeatedly.
I'm flexible. I like having control over how a project is engineered. I work well as a sole creator, as a team leader, or as a colleague in a larger team.
Some opinions about web apps
When looking for a job I naturally have to be prepared to adopt whatever technologies and standards my employer or client has set. But like any good engineer I have opinions about how to best approach architecting a software solution. Consider the following thoughts to be preferences and not hard rules for my work.
Most of my work over the past few decades has boiled down to creating web applications. There's usually a very complex suite of internal features for employees and sometimes external business partners. And there's a simpler, prettier set of features and more static content aimed at Joe Public. After so many iterations of this I have developed a pattern I favor. They are primarily aimed at making it fast and easy to create and change user features for larger scale enterprise apps with lots of operational data. Let me summarize some aspects of this pattern and explain why I favor them.
In keeping with that theme, the server side is ideally very flat. Page requests and JSON remote procedure calls (RPCs) get treated almost exactly the same as far as the coder is concerned. This greatly aids in testability and debugging. The most important key here is that the "middle tier" is nearly empty. This could be implemented in ASP.NET but just as easily some other server-side web platform. The middle tier is really just a glue layer. It shouldn't contain what you'd generally consider business logic. So where is it then?
Somewhere along they way I did a 180° on stored procedures. I went from putting all business logic in a middle tier that could sit on top of any database to putting all the business logic in the database itself. Why? Business logic comes in three flavors. First one is trivial reads and writes. What's the point of creating a bit of, say, C# code whose only purpose is to fetch a few records and package them up to ship to the client-side code? Why not just put that trivial logic in a simple SP? One that is super easy to create and unit test? The second flavor is painfully complicated queries. This is the handful of expensive searches you have. Or the monthly aggregate reports. This stuff is almost always nothing but complex queries that are best executed directly in the database. The third flavor is expensive batch processing. This is the scheduler algorithm that decides which customers need to receive which marketing emails when. Or the OLAP data feed that runs every night to power your data cubes. In any case nearly 100% of this is best kept in the database.
And let's not pretend we're going to run this against a bunch of different database back-ends. That rarely happens. And when it does you still end up having to write custom SQL for each of them.
And only extremely rarely will the middle tier need to get involved. It may be to generate an image file from data coming from a stored procedure, for example. Or to store some uploaded file somewhere. In almost all cases the SP gets executed first and sends special output data that instructs the middle tier in how to proceed.
The key to making this super easy for application development — and hiring programmers to do some of it — using this pattern is creating a custom framework for each big project. The framework ends up doing most of the heavy lifting. It gives your pages a consistent look and feel. It makes page layout a largely descriptive process. It powers all those app SPs on the back end. It takes some work to get it all ready. But it's so worthwhile. And improvements to the framework get inherited by all app pages.
I've tried N-Tier. I've tried MVC. I've tried code generators. I've tried an awful lot of the patterns in use in most mid to large companies. Most of them create enormous busy work for programmers. And they can be next to impossible to follow. In short they are expensive to employ in the short and long term.
And most of the third party UI frameworks disappear within a few years. It's one of the most important reasons to avoid them. Use the baseline platform and create your own minimal, application-specific framework.
One of the other benefits of this design pattern is that these apps almost always run very fast. Despite having rich UIs and being quick to assemble, the lightweight frameworks add almost no overhead and massively shrink the code you need to write for each page. And they let you focus on optimizing performance by adding indexes or trying out different designs with stakeholders to find a good balance.
I don't mean to suggest that the above works perfectly for every application. It really does cater well to larger enterprise apps, whether for internal use or facing the public. I'll also say that each time I implement a system like this I experiment with the exact frameworks looking for opportunities to improve on the previous app I made using this pattern. And sometimes the frameworks get trimmed down because a given app has more modest needs.