Michael Kent

Programming performance issues can be a frustrating and time-consuming problem for developers. However, tracking down these issues is a crucial step in creating software. Here are some steps that developers can take to track down programming performance issues: The first thing to do is ALWAYS hook up a profiler to your code, reproducing your issue, and measuring what is causing it. Performance issues are often not obvious and if you don’t profile you’ll waste a bunch of time speeding up things that don’t matter(or just hide the base issue).

Over the years Software Engineering has gone through many iterations of best practices. Form field validation is no exception to this. The morale of the story here is stop rolling your own validation. This is one of those things that seem super easy to do, so you just quick roll your own and then move on. Except you never move on because you’ll get tickets to fix stuff until the end of time.

Incident response is a critical aspect of software engineering – the process of identifying, responding to, and resolving incidents that occur within a software system. In order to effectively respond to incidents, software engineers can use the Incident Command System (ICS), a structured approach to incident management that is commonly used in emergency response situations. The ICS is a standardized approach to managing incidents that involves a hierarchical system of management and coordination. The system is designed to promote effective communication, coordination, and decision-making during incidents. The ICS is made up of five functional areas:

YAGNI and Agile One of the hardest things to do in software development is to respect “you ain’t gonna need it” and “keep it simple stupid”. Every time I go to implement a feature, I can think of 50 extra things I should do to make it ‘complete’ and exactly what I want. It is so helpful to hit things with an Agile and iterative frame of reference. Build an MVP(minimum viable product) and publish! Extra features can come later as they are actually needed.

Every time I make a file new project I need to add logging – how many times have I spent time figuring out what needs to go where, how to format the error email, and how to log uncaught errors(oh noes!). Too many times. So here is me condensing adding NLog to a web project quickly and easily: Install NLog.config(and with it NLog) on your web project. Add these to NLog.config:

The CIA triad of Confidentiality, Integrity, Availability refers to three necessary security components of software, at a bare baseline. **Confidentiality **Software(and its’ developers) are often exposed to sensitive details. These details should only reach the people the client expects. Users must be able to understand what data can be seen by who. **Integrity **Data should only be changed purposefully by users. Data, along with corresponding metadata, should be stored safely, securely, and with solid backups.

Some code smell I came upon today! Exceptions should always be handled in some way, even if just logging it and continuing on(the next person troubleshooting a problem will thank you). Also, exceptions should be exceptional – they are slow and break up code flow; avoid using them for normal circumstances, like bad user input. try { //do something } catch (Exception e) { }

How important is it that your software runs correctly and to spec? For most software it is of the utmost importance. One of the Joel Test 12 is “Do you fix bugs before writing new code?”. Smart development, testing, and QA help prevent bugs in software. Fixing Code Before Production and After Fixing code before it goes to production will save you time. I have had bugs that would have taken 30 seconds to fix before going to production that I spent more than a week on fixing after it went to production because it messed up data in another system.

Scheduling software is hard. Estimating software is hard. Deadlines in software are hard. When someone says “we need this thing you estimated for 4 weeks in 2” the question is “what can we cut or push back into another release?” Not managing the scope creep situation well ends up with: Increased Costs: Scope creep can lead to increased costs, as additional resources and time are required to meet the new requirements. This can impact the project’s budget and profitability.

When building an interface/class, a software engineer should think about how other software engineers are his target customer. This means that the interface should be designed with the needs and preferences of other software engineers in mind. Here are some reasons why software engineers should consider other software engineers as their target customer when building an interface: Efficiency in Workflow: Other software engineers will have similar workflows to the developer who is building the interface. The interface should be designed to facilitate efficient workflows, using well-established patterns and conventions to streamline the process.