Software Engineering Experiences

Dan's career in technology began as a programmer, and the journey you'll read here is one of Dan beginning at the lower level of abstraction as a programmer, and then moving gradually higher to focus less on lines of code and more on the interoperability of different subsystems to function as a product.

From there he moved up in abstraction again to focus on understanding how product function meets business objectives, and then he began looking at this from the perspective of multiple products. After that, he moved up a level to see how product design affects both client experience and corporate profitability.

Next, Dan began focusing on client needs and advocating to get those resolved within the products. Finally, Dan moved into sales where he focused directly on the client and began applying his knowledge and focus to all the products his company is able to sell - including services and partner offerings - and interfacing with all those product teams and specialties as needed on behalf of his client.

The whole point of illustrating this journey here at the start is so that you can understand how Dan began as a software engineer and retains the ability to do that today, but he's added unto that experience valuable knowledge and perspective from the business and client perspective. This combination of software knowledge and business knowledge along with his relational skills set Dan apart from many others in development, in sales, and in operations. Now, if you want more depth, here is Dan's long history with software:

Dan's Software Journey
When he was first recruited he had the option of joining any one of three different product groups. At the time he was a big *nix guy and loved OS-level stuff, so he joined a product group that developed a NUMA High Performance Computing Cluster. His first project was to port the open source "bind" DNS client to the proprietary HPC operating system. This was OS-level programming, but it was in the user memory space and not the kernal memory space. That project was completed successfully.

By the time he finished that first product his company (which had recently been acquired) announce the product was being discontinued. At that point Dan transferred to a small "Roadmap" group within the network-attached storage product development organization. That group was tasked with innovation - experimenting with new ideas and technologies to come up with new products, product directions, and other forms of innovation. His team worked on something called "object storage" before object storage was really productized and consumed. His team was probably five or ten years too early with the object storage concept, though that would begin really taking root ten years down the road. Unfortunately, the Roadmap team was a short-lived reality, and Dan soon transferred into a development group for an existing Network Attached Storage (NAS) product.

On that product team Dan became part of a group developing the management software for the NAS product. Development was primarily in C and Eiffel. This software ran in embedded code on the NAS system and allowed the administrator to configure the system. 

During his tenure on this development team, Dan's domain of responsibility included some security functions and test functions (helping QA team plan and create their tests) in addition to the coding. When software vulnerabilities were discovered (CVEs) for products or third party tools used within the code, Dan's team needed to work to determine whether their product was affected. Security planning also was a part of this software as the product was a mission-critical data center product potentially storing client's private data, HIPAA data, and even top secret (clearance-sensitive) data.

Dan also led a six-sigma driven customer support improvement team which developed a tool to collect logs and other system data from the product and a pathway to send it to support as soon as a problem is reported. This resulted in tangible improvements to customer experience as it minimized the number of round-trip communication requests were required to troubleshoot many problems and resulted in many customer calls being resolved much more quickly than in the past.

He continued programming as a software developer for around five years, after which he moved to another group within the company that allowed him to begin focusing more on people than on code. That was a Corporate Systems (Sales) Engineer position (CSE) and was in the Business Operations part of the product group he worked in. That CSE position did allow him to continue to do some programming, but it was primarily in the form of scripting (with some exceptions).

During his first few years as a CSE Dan focused primarily on the customer application of the product. He worked with the product teams to understand new and existing functionality, author white papers explaining how clients can use that functionality, develop training materials for internal (product and sales) staff as well as for customers, and create tools for technical sales teams. Part of this responsibility was creating and presenting presentations used to "train the trainer"  - educating those who are part of the formal training organization, those who are subject matter experts in field sales and support, etc.

After a few years focusing on customer application, Dan spent a year or so  leading a cross-functional "Total Customer Experience" team. That team took a hard look at numbers  and workflows related to product support in an effort to identify ways to drive down product service costs by enhancing quality, enhancing usability, enhancing education, implementing better internal process, providing better user experiences, etc. They had some wins, but Dan figured out he wasn't loving such a data-focused job and moved into the direct sales-focused part of the CSE organization: Strategic Accounts.

In Strategic Accounts Dan was a liason for assigned field sales teams and clients into the product engineering organization. (Think of it as "white glove service".) He mapped directly to several large accounts across different verticals that represented significant revenue or revenue potential for the product. He did cover a few strategic smaller accounts as well that were chosen either because of their spend or because there was a strategic business reason for giving them proximity to product engineering. 

During his time in Strategic Accounts Dan began gaining direct insight into the Sales organization, developing relationships there, and directly working with and even visiting clients.

After another few years of that an opportunity opened for Dan to move into field sales covering one of the accounts he had been supporting - a global Fortune 100 semiconductor manufacturer.  This was his most recent role, and his software programming need in this role was  limited to scripting for the first few years, but later grew to include programming on special learning projects such as providing an integration to Alexa, programming a Raspberry Pi - type board to do something fun, etc.

Finally, as a special project Dan has most recently worked on a python program for his personal faith interest. More on that later.

Projects Dan has worked on in software engineering includes, and is not limited to:

- Feature scoping and design
- Interface design
- High Performance Computing (HPC) operating system programming
- User interface programming for an embedded system
- Command line, application, and web programming
- as-a-service programming
- Database interfacing and queries
- Scripting
- Automation
- XML, REST, JSON communication interfaces
- Test interfaces / harnesses
- Code repositories (including github) and build automation
- Windows, Linux, Unix programming and automation
- Windows application, DLL, and MMC coding
- Windows and Linux ecosystem programming (domains, permissions, user accounts, LDAP,  etc)
- iOS app design

Software engineers tend to get the code written and then move on to other things. This is just a taste of the kinds of things Dan has worked on or utilized in his years of technology experience. It is not inclusive of everything. Reach out to him if you have any questions.

A sampling of kinds of software engineering projects was listed above. You may be wondering what languagues Dan used over the years...

Here is a list of languages Dan has used either extensively or lightly over his years:

- C,  C++
- C# and .Net
- Java, javascript
- Python
- Perl
- Visual Basic
- HTML / REST
- Windows and Powershell scripting
- Linux and *nix scripting

This list is not complete, but gives you an idea of languages Dan has been exposed to or used. It is a background that allows him to pick up other languages and learn them pretty quickly.

Reach out to him if you have any questions.

Software Architecture is one of Dan's favorite areas of software engineering. He enjoys building with code sometimes, but he really enjoys designing reusable, extensible, resilient code systems.

When architecting software, one of Dan's biggest areas of focus is abstraction by modularity and separation. He really dislikes a big, intertwined mess of code that just grows into a bigger mess over time. Dan prefers to carve up the software into areas of function and define interfaces to each area that are used rather than directly invoking functions or low level programming logic. This allows changes to the low level implementation without affecting the interfaces to that implementation... meaning that as long as the expected input and return requirements continue to be met other areas of code are unaffected and unaltered by those low level changes.

Aside from abstraction, Dan enjoys the challenge of trying to keep designs simple when designing software systems. He also enjoys the challenge of figuring out how to avoid reinventing the wheel when multiple subsystems need to do the same thing within their implementations.

Most projects Dan worked on were company confidential so they cannot all be listed here. A list of types of projects Dan has been exposed to is listed above.

Dan's views on code comments is very simply expressed: MORE IS BETTER THAN NOT ENOUGH.

Dan is a big proponent of good, standardized, code commenting. He's been through enough scenarios of having to rediscover his own code after many years and having to figure out the code of others that he is very appreciative of comments and supportive of taking the time to do them well.

Programmers need to have fun, too! 

Should it be mentioned that sometimes programmers hide fun "easter eggs" in code?
That's not saying that Dan ever did it, of course!

On a more serious note, Dan is a strong believers that programmers need to get out and actually have fun from time to time. Many programmers and some software architects are of a personality that needs a "push" or a "pull" to socialize with people they don't know. Dan discovered over time that he actually loves interacting with other people, yet he is able to relate to the "quiet and shy engineer" as well.

When it comes to managing programming teams, Dan is highly in favor of erring on the side of more of this interaction rather than less of it, and that means finding ways to get the engineers out of their normal context to do something together that isn't engineering (or that is engineering but requires social interaction with one another)!