The difference between a Developer and a HTek Consultant
- Hector Flores
- Aug 21, 2021
- 5 min read
I have wanted to write a blog about this for a while. The big thing I want to put out is that there is a vast distinct difference between a Developer a HTek Consultant.
Some serious breakdown of communications can arise when assuming that these two roles are one of the same.
What is a Developer?
A developer is someone that has the skill set of writing code. Being a developer does not mean that they can write any code; it just means they "write code."
Clients can spot a Developer when they:
Just Write Code
Just Fixes bugs
Attempt to use new trending languages/frameworks without considering the maintainability in the future. What I have seen is developers decide to use a language/framework that is so new, it hasnt been used by the majority of the development committee leaving the client to a small, expensive pool of resources that have the skill sets to support it.
Develop based on their desire to develop great code instead of your vision, priority, budget, and requirements. What I have seen is when a developer develops a feature with the mentality of favoring great code instead of the requirements of the feature it tends to show. You will get things like, "it does this because this other piece code needs it... instead of it does this because it follows this requirement"
Eager to rewrite everything to a "trending language/framework" they feel comfortable with. This is especially dangerous since this directly causes the clients budget to go our the window. Before making such drastic decisions, all alternatives need to be reviewed and risks need to be communicated to the client so that the client can determine if that is what they want to do
Start to develop strange rates. What I have seen is developers underestimate their work (Due to the reasons above). Where it becomes a problem for the client is when the developer gets frustrated with there own incorrect estimations and starts to charge rates that are off. There should be a projectable, reasonable, and consistent rate at all times. If work is being underestimate, a conversation needs to be had on what is the cause, developers over-engineering, clients lake of requirement details, or developers lack of understanding
Don't have any planned/documented architecture. Developers usually lean a lot on tools to handle the infrastructure. For that reason, rarely will you find a developer who knows how to design and implement an architecture that will be secure and reliable for the client in the future or on specific loads. Clients need to ensure they have well documented what there architecture looks like all the time
Don't have any planned/documented automated hands free development process. Not starting with an automated process from beginning will leave the client in a situation where they will rely heavily on the developer to publish changes and configuration setup "manually". The client would not be in a good place since if the developer leaves, the client will be left with a solution with no means of changing or deploying. Also, in around one year (If not sooner), the solution will start to fall apart since that is around the time most configured "secrets" expire and the client has no means (That is reliable and repeatable) to reconfigure them.
Cant give projected costs of the cloud infrastructure. Most developers (As said above), use tools to handle the infrastructure. The developers' tools to stand up the infrastructure are usually "developer friendly", meaning they have built these tools to make it easier for developers. This could compromise the quality of good cost reporting, disaster recovery, security, or even a backup process. Not saying none do; I'm saying they are geared for developers and not for clients. This will leave the developer lost for words when asked such detailed questions on cost.
Have poor communication skills. Developers like to be in their world, "Give me some task, leave me alone". The type of repour the developers will have with the client becomes disjointed and is where the developer starts to become unaligned with what the client is expecting. This is where the client will be nervous not knowing if what they paid for will work at the end.
Have the following response when the client informs the developer of a defect. "It works for me...". Often, this is true, but the proper way to interact with the client here is to be engaging and find why it works for the developer and not the client, and to consider user experience issues (how the client is using and experiencing the product) as a defect
What is an HTek Consultant
An HTek Consultant is to come in and understand a client's vision, history, and motivations, then translate that to something realb that have to tools in place to last a long time. Specifically,
HTek Consultants commits to
Learn the clients' vision, motivations, fears, history, and gaps
Provide excitement, inspiration, and drive to give the client momentum to move forward
Provide processes, direction, tools, support, estimations, approvals, control, and monitoring which will be the core for how the consultant and the client perform their day to day interactions
Interact with the client regularly to align priorities, budget, approvals, and requirements
Translate a clients vision into an actual solution that
Satisfies the clients' base requirements, priorities, and budget
Adheres to the consultants standard of compliance in security, scalability, maintainability
It's delivered in a reliable, automated, repeatable, approvable, and traceable manner.
Clients can spot a HTek Consultant when they:
Ask a lot of questions.
Get into the clients head in ways no other consultant ever has
Be extremely passionate about what they are about to deliver to you.
Be energetic and full of life no matter the situation the engagement is in
Provide past examples that will inspire the possibilities for the client
Provide a Development Process
Provide a Delivery Plan/Process which includes approvals, control, and monitoring to the client
Provide the direction for the technical requirements needed to fulfill your vision
Provide the staffing required if needed to be fulfilled by the client to fill in any gaps in expertise
Provide estimations of any proposed direction and or options to the client along with the risks with each
Provide the tools used to facilitate, manage, monitor the defined Development Process, Delivery Plan/Process, Implementation, Staffing, Estimations/Actuals tracking, and documentation
HTek Consultants can spot a lousy client (Loosing out on the benefit of HTek Consultants) when they:
Skip any of the consultants' compliance requirements
Expect work for free/cheap
Expect fixes for several bugs the client texted them at 11 PM
Don't follow the regular meeting cadence as the consultant directed
Do not take approvals seriously and instead opt to give all access for ease.
Take away
If you didn't make it through the details, remember this, HTek Consultants are not just developers. Start to notice if your resources are developers or consultants.