A discussion on web development

I enjoy talking about web development. It is a passion of mine. The first time I touched HTML was in 1994 in the computer clusters at the local college (University of New Hampshire), looking at my hacked together tags in Netscape Navigator. There I discovered that my affinity and love for computing outweighed my motivation and attention to school work; you may notice I have possess no degrees from UNH. Despite this, it inspired me to continue on that path.

I was very fortunate in my youth to have access to computers at home with a father for an engineer. I had early access to computers in our home, and that allowed me a certain freedom with them, as I got older. This became a passion the expression behind web development. The early medium I saw always had so much potential.

The Internet always felt fast to me; still does. Web development feels like a natural progression of human interaction and communication. It gives people a simple avenue to express ourselves to one another in ever-changing and complex ways.

The technology itself has changed so much since then, and I, hopefully, along with it. Web development and creating software applications in this space is special to me because of my history with it, and because the complexity of it is only as much as person allows. Web development is filled with funny buzzwords, especially in the hiring process, the same way we use them inherently in software development and engineering.

To be clear: Buzzwords are for making people feel dumb when they do not know what you are talking about in the first place. They were inherently there with networking; I did that, too: VLAN, Subnetting, BGP, IGRP, EIGRP, OSPF, et al. Acronyms and buzzwords are also ways to make it easier for people within those industries to distinguish themselves from one another, and to talk quickly about specific concepts.

Software development and engineering as process, SDLC, OOP, OOD, Agile, Scrum, CMMI, XP, TDD, et al. They are concepts for larger, more theoretical discussions about the nuances in efficiency in the process of making software. It is interesting to discuss theoretically, but practically, the ideas are things that most software developers and engineers should not be inherently concerned with directly. We are there because we like to code and program, and the processes that are all out there still depend on work being done.

Web development is no different from those industries. You hear things like, Full Stack, Back End, Front End, UX/UI, etc. Many of the problems with these terms are the misuse and mishandling of them. A Full Stack developer can do what exactly?

My definition varies, but generally, I would expect a Full Stack developer to traverse the technologies used. In our case in a .Net shop, from HTML, CSS, JavaScript, and Page Life Cycle to Web Sockets, HTTP, ASP.Net, MVC, C#,  and SQL, SQL Server, and No SQL databases. I have worked and am working with amazingly talented people, and trying to label anyone into this little chasm of technologies is unfair because it is all something that is part of the moment.

That said, job posts for people who do not list the technology stack used in bold, up front, are doing a disservice to the hiring process. 

The demands of web development are different than a number of other types of development, simply because of the rapidity that technology changes. We inherit code libraries that release new version almost monthly or more quickly. We write code in both interpreted and compiled languages. We need to understand data access, management, and entity handling. In my opinion, it takes an odd type of programmer to traverse the technology stacks, as you need to adjust your approach to programming to embrace the nuances of the way the technology all interacts.

Web development is visual, so any team without a designer who understand HTML and CSS is crippled slightly, because you are probably doing it the old way. The old way: a designer makes a bunch of "comps" (compositions) of the imagined web pages with some guidance on what might be possible with the web technologies, passes them over to development, development opens the files and literally rips apart the image layers for use on the Internet. Web design should be more organic than that. A designer must know the limitations and understand best practices to modernize a web development team.

 The monkey wrench in the idea that web development is visual is service oriented architecture and design. This is where a “web application” extends other software gets to the web. Despite all the principals, if it does not need a browser to work and function, it is not a web application. Service-based web applications have their place, and I have written many, but they should not be the basis for using the term web development. It is a component in something greater, and I stick to: web development is visual. 

With that mantra, you have to stick to the idea that all web applications are meant for people to consume. We all want to make web applications that are intuitive, functional, performant, stable, and secure. Those tenants should be the guiding principle for any web application. The intuitive part of that is the human-computer interaction bit, where you know your audience, and your audience is people. If something is easy to do because it is simple and straightforward, people will enjoy using it. If an application does as advertised, you have the functional concept fully covered. If it does as advertised quickly, and without crashing repeatedly, it is both performant and stable. If it does all of that without exposing a user's personal information inadvertently and keeps it stored safely and securely over time, then it is secure.

When I talk to a developer for a job, I am typically looking for someone who can cover all these bases. You really want someone who understands these approaches with web applications. Then you get programmers who are focused on quality and customer experience, rather than delivering something too early and half-baked. It is a difficult situation from which to recover, and often quite expensive. 

I love the idea of talking to people who are willing to sound ideas back and forth while troubleshooting problems. It sometimes feels like I do better and more programming through dialogue with other developers than I do alone, though I expect some problems are still one-person jobs. To me it is all about understanding customer expectations clearly, meeting them, and making them understand that you are not willing to sacrifice quality, (intuitiveness, functionality, performance, stability, and security).

Thanks for listening! This is just a bunch of passionate opinions on web development from a person who is still making his way along in the dark like everyone else. I worked and work with a multitude of fun stuff, and look forward to meeting the challenges of more new technologies in the web space as I continue on this journey.