Joel Elliott
Computer Programmer
Mission
Developing excellent software to solve problems.
As of now (in 2024), I have 19 years of experience in cross-platform application development for corporations. I have an unending interest in learning, and already have experience literally from front-end to back-end (HTML to SQL database optimization) and from A to Z (Assembler to z/OS). I look forward to gaining new knowledge and experiences whatever is next.
For a quick overview of my past experiences, I have maintained systems written before I was born, helped with a migration to a whole new policy administration system, added logging infrastructure, and developed new applications. More details are listed below.
But first, some points I want to highlight, on a more philosophical level. If these things seem obvious, we will probably get along well; if they seem interesting, they are hopefully a good topic we can discuss. But if the leadership at a company disagrees with these, then that is a red-flag for me working there, best brought out up-front rather than months after taking a position.
I believe good leadership is the only way to sustain quality over time. Most people want to be really good at their job, and are happy to stay with a team which created something valuable in the first place. The reasons things fall apart come down to fear, short-term thinking, and people not being valued. A good leader puts the good of the group first, and knows that includes recognizing the value of people, and the future of their products.
I believe there is no substitute for expertise, and that programmers cannot write truly high-quality software without some real understanding of its usage. Many times I have been on a project which officially has the full written requirements "completed", only to find a very large gap between true requirements and what was written months later. Some ways to resolve this include "dogfooding", connecting developers directly with business analysts, training in the industry's field of business, etc.
Developers work at their best when they are solving a problem they are invested in. That is, when you care about the thing you are building, you will be more creative, and end up getting better results. Because of this, yes it is great to allow developers to solve problems they are interested in; but that is of limited value. Instead, more effort should be spent to show how the business can affect our users, to try sparking interest and connection with ourselves.
Senior Developer @ EXL starting 2022
Primarily developed integrations of a Life Insurance policy administration system, to fit the needs of clients' existing systems.
Wrote many "extracts", basically advanced queries of policy data, iterating through many changes in requirements. These included extracts which are centered on policy data, agent commissions, accounting, etc.
Co-developed an application to ingesting agency data maintained in an external system.
Co-developed a structure to customize print-data more easily than the existing approach, appending elements pulled directly from the policy database.
Started an internal wiki to help internal documentation be easier and more collaborative.
Worked with Microsoft SQL Server, git, C#, communicating with MS Teams, Jira/Atlassian, and of course email.
Lead Programmer Analyst @ American National from 2004 - 2022
Primarily developed and maintained components of a policy administration system for personal insurance, working with COBOL and .NET.
Promoted five times since initially being hired.
In 2020, as a co-team lead, helped maintain numerous legacy systems, with constantly changing priorities as we transitioned to a new admin system.
Helped lead a project to implement eSignature integrations with a vendor system.
Wrote, revised, and maintained a simple application logging infrastructure.
Wrote a generic implementation of HTTP 1.0 in COBOL, using IBM modules for TCP/IP and DNS.
Web/Open Technologies
HTML - in ASP.NET applications, as simple proof-of-concept demonstrations, and even generation of raw HTML pages out of COBOL. Also a few side-project websites (like onetimepad.glitch.me).
CSS - as needed for basic functionality, and to add clarity to presentation; nothing very fancy.
ECMAScript (javascript) - only raw text. That is, I have written plain javascript for hundreds of lines in modules, but I have not (yet) used TypeScript, or any large frameworks past borrowing them to solve a single problem.
XML - as the primary format for webservices and documents.
Utilities - Chrome (developer tools), Notepad++, WinMerge, Paint .NET, Postman, Google Docs/Sheets/Forms/etc, Audacity (occasionally recorded and edited as a hobby).
Microsoft Platforms
C# and VB.NET - significant development and maintenance over many years. Mostly implementing business projects, but also including version upgrades, migration from VSS to TFS, and redesigning API's to be more clear and useful. Mostly applications hosted as IIS websites, but a few desktop "Windows Forms" applications as well.
Microsoft SQL Server - as a component of some complex applications, I helped design and maintain multiple databases for years.
Active Directory - as needed to maintain application permissions, and some trivial research and development.
Utilities - Visual Studio, SQL Server Management Studio, Word, Excel, Outlook, Active Directory Users and Computers, OneNote, Teams.
Deprecated - grew up learning DOS batch commands, through Windows 3.1 and all major versions since.
Mainframe Technologies
COBOL - years of application development.
CICS - terminal screens (using SDF II), called modules, webservices exposed over CWBA, and also using third party software (InnerAccess > DataDirect > Rocket, and z/OS Connect).
DB2 - countless one-off queries and reports, and frequent use in application development embedded in COBOL programs.
JCL - batch job applications, and regular use for utility purposes (search, compare, ftp, etc).
Utilities - TSO, SDSF, ASG-SmartEdit, AbendAid, ZEKE, BMC Catalog Manager, XPEDITER, SYNCSORT, IDCAMS, SDF II.
Soft Skills
Documentation - I advocate for an open system of documentation, on the internal company network. I prefer MediaWiki (Wikipedia's software), but any system is great if it is both searchable and easy to edit. While I strive for self-contained technical clarity, I see major limitations of this within most systems, and have found this need best met with a collaborative documentation system.
Research - I am very comfortable both independently researching questions online, and also asking for help whenever needed. I love to learn all of the details of the systems I use, often going to reference documentation, and usually becoming one of the most knowledgeable about all systems within my domain.
Mentor - As I became the expert on various systems, I have found more and more people coming to me with questions. I am happy to share knowledge, although sometimes I "go too fast". Loving to share knowledge is partly why I advocate for a wiki system, where we can grow the collective understanding together.