A company's biggest resource is its team, its people. Nothing compares to the ideas and innovations that the human mind can devise. No other resource in your company, neither finance nor technology, is as valuable as your best people.
People are also the most challenging resource to manage, and leaders have the tough role of managing them alongside finance, workflow, technology, and everything else involved in the product development process. So naturally, when you're leading a team of people and the results are suboptimal or not up to your expectations, you might ask yourself, “Should I keep investing in my team? Are they worth it?”
Deciding whether to continue investing in people or cut losses is a hard decision for any team leader, and it always comes down to the specific conditions of a situation. So, before making any decision, a leader should analyze all the factors that contribute to the obstacles individually.
Here are a few questions team leaders can ask themselves to get relevant information that will help them decide:
Often, people’s knowledge and skills are not the issues – it is poor organization and communication. The team either lacks direction, information, or inspiration. Therefore, they lose the motivation to finish their tasks, let alone work on continuously learning or improving. So rather than taking the easy way out and cutting them off the team, good leaders will put some skin in the game and bet on the people. Instead of blaming the people, they will roll up their sleeves and work on the organizational aspect – corporate communication, processes, and culture.
Betting on your team is never a losing game – in fact, it’s the trait of a leader to find the courage to embrace potential failure, nurture people’s potential, and believe in them.
Common mistakes new managers make
How many times have you looked at your manager and thought
“If I were in their place, I would do things very, very differently”?
If you’re like most people, then the answer is – a lot!
Simon Sinek says that stress and anxiety at work have less to do with the actual work we do and more to do with weak management and leadership. This basically means that it all comes down to the human element, or rather, the human touch – which is especially important in an industry like ours, where most of the work is tech and data oriented.
When it comes to new managers, or people who have moved up from their previous role, for example a software engineer who has been promoted to a manager, where they’re responsible not only for themselves but for an entire team, there are a few areas where mistakes can often occur.
So, what are the most common mistakes new managers make and how can they be avoided?
1. They don’t own their new role
A lot of the time new managers forget that they’re no longer just part of a team, they’re now managing the team, which requires a completely different set of skills. This means that they need to put their manager’s hat on and start looking at things from a different perspective.
By talking to more experienced managers in their company about how they approach their own role and team, they can get some insight and perspective on how to better adapt to their new job.
2. Instead of becoming leaders, they become authoritarians
There is a difference between just being a manager and being a true leader – a manager tells people what to do, but a leader motivates and inspires them to become better at what they do.
A lot of the times new managers (especially ones that are slightly younger) tend to let their newfound “power” go to their head and start handing out orders in a way that imposes their authority on others.
For example, they come into work and instead of talking to their team and using their soft skills to motivate and inspire them, they use only the authority of their title to get people to do what they want.
It’s not just about having the authority to delegate work, it’s about leading by example. In order to be a good manager, you have to be a leader – and you become a leader by caring for other people and uniting them under a common goal that has everyone’s best interest.
3. They refuse to listen to the experts, and they get in their way
Often times people think that just because they’re now managers, they need to know everything, and they need to be the smartest person in the room.
Great managers know that for their project to be successful, they need the right people to do the right things, at the right time.
You don’t need to prove that you’re the smartest, most experienced or fastest person in the room – you just need to make sure you have those people on your team and then get out of their way so that they can do what they do best.
4. They succumb to micromanagement
A lot of the times people think that the responsibilities of being a manager involve overseeing every detail in the project and being intensely involved in every single part of it.
For example, a new and not so experienced manager thinks that nothing will get done unless they’re involved in the entire process – from idea to execution. So, they sit down with every person for every single task, they tell them how to do their work, check in on them constantly, organize unnecessary meetings, etc. This approach will surely lead them to burnout, leaving the team feeling frustrated and incompetent.
The beauty of a management role is that it allows people to focus on the big picture, to strategize and to contribute towards making the changes they want to see on their team. Managers should always have one eye on the future, instead of both on the present.
5. They lose their sense of curiosity and often become completely different people
Rather than taking the knowledge and experience from their previous role and using it to fuel their desire to improve and innovate, new managers often start detaching themselves from their team as they now find themselves in a completely new and unfamiliar position. They stop communicating openly and often lose the ability to give and receive open feedback.
How can this be avoided? By remaining curious, rather than being assumptive.
Instead of guessing or assuming they know why tasks are running late or why employees are doing things a certain way, they need to be curious enough to ask what’s happening,
There are many things that can make a manager either good or bad at their job and they all depend on the circumstances. But at the end of the day, it’s a leader’s job to have the courage and determination to put themselves at risk of facing uncharted waters in order to open up a new path that others can walk on and make things easier for their team, and that is one trait that definitely makes a manager truly great – even if they are new at their job.
What makes a good engineer great?
Behind every great software there is a team of great engineers. A team of people who use their distinctive attributes to develop powerful solutions to our modern-day problems, who think progressively and take their work to a level that overdelivers.
But what makes an engineer truly great? What is it that sets them apart?
There’s a general misconception that going from good to great requires a giant leap forward in know-how, skills, and knowledge. But if you take a closer look, you’ll see that, as in most cases, “the devil” is in the details.
Exceptional engineers give a little bit of “extra” to everything they do, at any stage of the process and they know that when you add the little things together, they amount to a lot.
So, what do great engineers have in common?
1. They are curious, open-minded, and innovative
At its core, software development is a problem-solving endeavor. A great engineer is always curious and open-minded when it comes to solving problems and can change their beliefs and predetermination when they’re presented with new information. They go looking for new answers, rather than thinking they already have all the answers.
2. They are able to simplify rather than complicate
The landscape of software constantly changes and gets more and more complex over time. A great software engineer knows to factor this in from the very start and is able to weave simplicity into their work.
3. They are ambitious and self-motivated
Engineers who can see the bigger picture and can motivate themselves will always be a step ahead, because they’re not relying on their environment and surroundings to keep them going and give 100% effort to the project.
4. They are strong communicators and work well in teams
There’s an old African saying “If you want to go quickly, go alone. If you want to go far, go together.” The ability to communicate openly and work together with people is an amazing skill that helps the team to power through obstacles and tough times.
5. They know the value of everything, not just the software
Great engineers know that there’s value in everything – feedback, different opinions, innovation… and most important of all, they’re able to determine what matters most at any given time in order to maximize value and contribute to the project.
Even though there’s no magic formula to becoming a great engineer, it continuously goes to show that it’s the little things people tend to overlook that end up having a big impact.
The difference between an average and a good software engineer is simple – technical skills and experience. But the difference between a good and a great engineer lies in all the nuances of using personal skills to add even greater value to the final product – that’s how you deliver beyond what’s expected.
Chat GPT for development
Can you rely on ChatGPT for secure coding?
If you have come across any of social media "Stop harassingChatGPT" posts, or maybe tried to check its limits, you are aware that sometimes it may struggle with basic math and simple logic. This is totally understandable having in mind that it was educated on people's historical and current collective writing worldwide and unfortunately, it's still not the robot butler that you've been dreaming of. The problem is that it often presents entirely false facts with a confidence of a four-year-old in a Batman costume.
While it can be a great learning tool in some cases when you need some complex subjects simplified, you must remember its biased behavior and
never fully rely on the data it provides. This is especially important when it comes to coding, since there are a lot of security issues to be aware of.
Where ChatGPT fails to support you in coding
• It doesn't have enough data for the ever-evolving secure coding best practices. ChatGPT is not updated with the latest threats, vulnerabilities,and attacks, as it is not linked to any cybersecurity framework.
• Chat GPT cannot guarantee about misconfiguration issues, as it is also the biggest flaw in human coding.
• It cannot perform security review of the code, nor to ensure authenticity of external data sources.
• It has no advanced secure coding capabilities to make assessment of the code in terms of weakness and vulnerability.
• There is no assurance for the safety of the code it produces since it is not designed to take account of the saved data it generates. This can
impose a threat for the IT ecosystem where you plan to deploy it. Think about API keys, tokens, login pairs and log entries.
How to leverage AI in secure coding
AI-powered tools can help you address potential security flaws in the code you build. But the result is only as good as the developer’s intentions and depth of understanding. So, if you are a coding newbie without full knowledge of how coding works and how to secure it, you'll haveto improve your understanding of coding and cybersecurity to take full advantage of AI coding and AI secure coding solutions.
Technology is here to make things easier, and it would be foolish not to use it as support. However, the only smart way to gowith it at this point is to be open to learning how to useChatGPT or any other AI tool but invest in developing your other skills, too. Remember that people are still the pillars of fully working coding solutions.
Every once in a while you will be in a position to solve the challenge of writing and maintaining a professional technical documentation for your product REST API. Building an API is easy, right? Technically speaking it is. The biggest challenge comes when someone has to use your API for the first time. It is then, when you figure out that no-one except for the development team understands what the hack is going on behind the scenes. To avoid this potential pitfall, I would like to share our personal experience with our product’s API for sending invoices – Envoice.
Businesses today have complex business processes which expands over different software systems. Today most used software systems are not the ones that are offering plenty of functionalities, but rather the ones that offer API and out of the box integrations with other popular services. Having said that, if you are planning your next venture or already developing a product you will need to spend some time to get the things sorted and allow your customers to integrate your service as part of their eco-system. There are several aspects you need to consider when preparing for API development including:
2. Writing an API endpoint
Since you are reading this post I would assume that you’ve already created a Web API 2.0 Controller as in the example bellow:
We have an endpoint that describes the process associated with the “Client” domain entities. We’ve decided that we would like to enable the developers to programmatically:
2.1 What kind of actions you are going to allow through the API?
First things first, we need to decide what type of data we are going to process and return back to the consumer. Ex: Mapping client details data call Client API:
In our example we have a custom DTO that we are going to use as a response when retrieving details about the client.
2.2 Securing the endpoint
Besides setting up a RequireSsl attribute, we need to make sure that we can identify the caller when accessing the API. Let’s say we need to secure the process of creating a new client.
A simple yet effective approach would be to use “API Auth Key” and “API Auth Secret”. With RNGCryptoServiceProvider we can create an Auth Key and Secret and associate them with the user’s account. Make sure they can be regenerated. Note: Recommended key length would be 128 for both Auth Key and Secret. To be able to authenticate the call, implement Application_AuthenticationRequest method in Global.asax.cs.
All request that require authentication should contain an Auth Key and Secret headers.
If the key and secret are valid, we will allow the request to be executed. This verification can be achieved with a custom authorize attribute.
3. Tools to document and maintain the API documentation
At the moment there is a huge support and community activity around Swagger – framework of API development tools for the Open API Specification. In our favour, it is supported in the .NET eco system via the NuGet package: Swashbuckle. Installing this package in your Web application, will add support for Swagger 2.0. After the installation you will find a newly generated Swagger configuration file under App_Start\SwaggerConfig.cs.
The configuring is extensive and allows you to go into details on generating the open specification for you API. Once done, you can check the results on your predefined API documentation route. The generated API specification will contain all of the exposed Web API methods together with the associated comments and DTOs. The associated comments are going to be read from the XML comments from the output directory. Usually that is Project.Namespace.XML.
3.1 Configuration extension
Since the requirements may vary, you might end up needing a functionality which is not supported out of the box. Great thing is that you will be able to write extensions and override the process of creating the API specification. In case you need to extend, you can write the following types of extensions: – Operation filters – override the specification on an operation level. Ex: Create a new client action; – Schema filters – override the specification schema. Ex: exclude a property from the request/response; – Document filters – override the document. Highest in hierarchy. Ex: Set all operations to lowercase; There are many useful examples that can be found on Swashbuckle for Document, Schema and Operation filters. Make sure you check them before rolling out on your own.
3.2 Generating a usable UI/UX for your API specification
I understand that developers are not always happy when it comes to creating a usable UI/UX, but it is a prerequisite to have good API documentation. Swashbuckle offers an UI out of the box, but it is poorly designed and renders raw information from the API specification. There is one library that comes to the rescue: REDOC. Redoc lets you generate a modern UI by simply providing the library with the absolute URL to the API specification.
You should get the following result after refresh:
3.3 When documentation is not enough
Often after releasing the API, you will face the hard truth, that the developers who are integrating your API with some existing product out there will need help to understand what your API does and how they can use it in their programming language. This can decrease your team productivity time, as you will spend countless hours into explaining how to use the API in .NET, PHP, Go, Ruby, Python. In order to cut down the time spent on support, there are some activities that you can do beforehand: – Creating a Postman collection; – Creating cURL examples on GitHub; – Embedding the Postman collection and GitHub examples as part of your API docs; Postman allows you to create an environment from which anyone who is interested in your API can utilize it to execute requests, explore the API capabilities and export the examples in their preferred programming language.
Having this, will save you from the trouble to write and manage client libraries in different programming languages and to reduce the learning curve for your custom libraries.
4. Wrapping up
While you keep developing your API don’t forget that your documentation will be updated automatically but you will still need to update your Postman docs and GitHub examples. While iterating, reserve some time for maintaining the documentation and analyze you haven’t broken your existing client’s integrations.