Confessions of a Coretechs Developer
October 4th, 2023
Our developers build your software and create tailored solutions to solve your toughest problems. Today we’re highlighting things they want to tell you but can’t – these are their confessions.
Picking an arbitrary deadline before consulting a developer sets unrealistic expectations.
When we start a new project, we have several standard questions like:
- What do you already have?
- Which code languages are being used?
- Do you have an urgent deadline?
When we ask about your deadline, we’re asking so we can allocate resources and set expectations for milestones. But when a client sets a random deadline, it can take a project from fun to failure in a second.
Many times, project managers and clients ask for features or products as fast as they can get it and that sets an unrealistic time frame that results in rushing a project and possibly delivering buggy code. When we have time to plan and think through a project, we’re able to come up with scalable and sustainable solutions that keep your business ahead of the curve. Sure, it might take longer for the project to go live, but it also allows us to have more conversations with the rest of the team and client to make sure we’re going in the right direction. If you don’t have an urgent deadline, let your team recommend a timeline and delivery date.
We love your products because we think the technology behind them is cool.
We LOVE what we do. We follow developer chat boards in our free time, we read about the “hottest” and “latest” upcoming languages, and we use your products because we think the way they work is COOL. Our team often tries out the latest technology and softwares not just to know about them, but to figure out which of your projects would benefit from them! We love to experiment with new technology, so any excuse we can find to play with and use your product – we’ll take it.
We know that you think your product is magic, but really your developer is a creative genius.
You’ve got problems and we’ve got answers that are written in a super special secret language; that sounds like magic to most people. Although there are times we literally impress ourselves, our solutions don’t come from spell books – they come from dedication, study, and ongoing development (pun intended).
Our magic comes from the ability to problem solve. Sometimes that means we test for hours before we create the right fix to a persistent bug. Other times, that means that we put our heads together and debate the right way to structure a database. The magic is in the solution, which takes not only a creative approach but a willingness to try something new.
More developers on a project does not equal faster development.
Many of our successful projects have one lead developer who knows the “big” picture. That developer can break down tasks and give them to additional developers to help move the project to the next milestone.
Sometimes, when a project isn’t moving as quickly as a client wants, they want us to add more developers to the project – we HATE that. We don’t dislike working with more developers – we love having the ability to bounce ideas of one another and collaborate. But adding more developers to a project means more coordination and planning.
Code for a project involves lots of moving pieces and when developers are working together our code often intersects. If we aren’t properly communicating, it is very easy to overwrite another developer’s code or remove something a co-worker spent time creating. If you think accidentally deleting your own work is bad wait until you’ve accidentally deleted your colleague’s work. Before you ask for more developers on a project, consider extending your time frame.
You might think your code should do “something”, but we spend a lot of time with code, and we know better.
Not all of our projects are started from scratch. Many of the projects we work on already have an existing code base. The code has been written by other developers, sometimes it is in beta mode, but often is already being used by actual users.
When we start looking at existing code we’re like mechanics looking under the hood of your car. We expect it to be neat and tidy and to do exactly what the client says it does, but most of the time there are surprises that the customer doesn’t know exist. Clients usually tell us what their code does, what language it is, and as much as they can about their project. But when we see the code, it’s a lot louder than the customer description, and boy does it yell.
Lots of our code is “Open Source”. We do not reinvent the wheel for your project.
Open source code is code written by someone else that is allowed to be shared and used by other developers. Remember our confession that we follow developer chats and check out new technology in our free time? This is where we find and learn about different open-source code.
We choose open-source code so that we can develop faster and more efficiently for our client’s to keep projects on time and on budget. It allows us to spend more time solving problems and creating custom solutions for your unique problems than on setting up familiar problems that face all businesses.
Our developers truly care about your project and have your best interests in mind! Trust that we are recommending the best solutions for your problems when we create your software and web applications.