Rules of Engagement for a software engineer

  1. If you are stuck on a single problem for more than three hours it is time to call help.
  2. You work for your manager not for company. Is it?
  3. Keep your ideas to yourself until you have more around them, like useful impact for team, reasonable confidence of execution, POC & estimates 
  4. Best part of day must be spent on very important and more impacting work 
  5. Never over promise – which inevitably leads to under delivery. Always under promise and over deliver. 
  6. Tech debt vs timely delivery – always let the later win. Nobody loves a delayed but perfect release. (It may not even be that perfect)
  7. 20% of your time should be spent on something your manager is not aware at this instance. Provided you always work 20% more time than average.
  8. Consistent schedule is preferable for your health and your team’s health. Remember Rome is not built in a day.
  9. Know and understand dependencies of the feature before you write submit first draft of plan.
  10. Know your red-flags, and feel free to jump ship before they eat you alive.
  11. Every morning and evening write personal logs (as simple as OneNote )
  12. Nobody likes a smart-goblin.
  13. Always go prepared to a meeting.

The Highly Scalable system by humans is the family

 

Apparently the highly successful high scalable system designed, evolved by humans is neither AWS nor Azure (nor Google Cloud not OCI nor FB one), rather it is the unit of family.

Imagine you are given a task to organize seven billion entities and yet –

  1. be productive
  2. be competitive
  3. be mindful
  4. survive and propagate
  5. be selfish and at the same time be helpful to other entities.
  6. etc…

Your brain is going to explode isn’t it ?

But humans did it with a simple design called the family.

Git(hub) feature request – Make Code review comments available to developers forever during their edits

One of the recent trend is to minimize quantity of comments inline in code files and improve quality of comments. This caught up like fire and moving towards the danger zone of no comment-era. This is all good provided the code is written with maintenance in mind and not for short term goals of long running product to satisfy some OKR set by somebody higher up or to meet some dead line which coincidently aligns with your performance review period 🙂

I am all for those learning of clean code. Good variable names, smaller classes, smaller methods, meaningful names to methods, highly readable code, lesser number of lines of code, let the compiler worry about optimizing my code etc…

But this comments is a tricky thing. when the code is written first time a lot of thought goes into it. compromises will be made, hard decisions will be made. Developers are moving intra-companies, inter-companies like crazy Salagars. All this context is lost for future developers. Now they are told more comments is bad pattern.

One natural place for all this information is code review description, self-comments, discussions. It is already happening there – just that this information is not easily available to future developers readily.

If Git(hub) can find a way to make this information available to editors (e.g.. VSCode, which already shows lot of Git history while you try to edit a code-file) it will be pretty useful to developers who are trying to fix that nagging bug and keep swearing “who the fuck wrote this shit and why?”

stringObject.IsNullOrWhiteSpace() a simple c# extension method

Every time doing String.IsNullOrWhiteSpace(input) is irritating. Moreover we try to input. and look for this method in intelligence. But it won’t be there, as it is static, unless we do String. we don’t see this method.

Writing an extension method will save us this trouble.

public static class MustHaveCSharpExtensions
{
	public static bool IsNullOrWhiteSpace(this string input)
	{
		return String.IsNullOrWhiteSpace(input);
	}
}

c# new feature request : AutoInitListsOnFirstUse

Another sugar coating – a compiler should easily generate code for this (?) without any side effects. why force people to do new boiler plate code ?

List<string> myListOfStrings;

myListOfStrings.Add(“firstString”);

This throws NullReferenceException until we do new List<string>();

The probability of it happening is more when this is part of another data class, which we initialized but forgot to look into all hose other initializations we need to do.

In case somebody want to avoid this behavior we should have an attribute to support old behavior.

[SansAutoInitListOnFirstUse]

Creating dotnet solution, project and test project with cli

This is a good source. https://docs.microsoft.com/en-us/dotnet/core/testing/unit-testing-with-mstest 

mkidr MyConsoleProjectWithUnitTest
cd MyConsoleProjectWithUnitTest/
dotnet new sln
mkdir HelloWorldConsole
cd HelloWorldConsole/
dotnet new console 
(or dotnet new classlib for creating Library instead of console project)
dotnet run
cd ..
mkdir HelloWorldConsole.Tests
cd HelloWorldConsole.Tests/
dotnet new mstest 
dotnet add reference ../HelloWorldConsole/HelloWorldConsole.csproj 
cd ..
dotnet sln add HelloWorldConsole/HelloWorldConsole.csproj 
dotnet sln add HelloWorldConsole.Tests/HelloWorldConsole.Tests.csproj
code . 
# Make modifications to your tests, program. 
Cd HelloWorldConsole.Tests
dotnet test 

c# using custom attributes to validate prerequisites for methods, controller APIs

If you have bunch of prerequisites to be validated for more than one method, we could make code more cute by using an attribute.

For normal methods, this new custom attribute’s constructor could throw exception in case of failure.

But throwing exception in Controller API is bad idea. We want to return more gracefully.

Instead of extending Attribute, extend AuthorizeAttribute and override IsAuthorized() [ or AuthorizeCore() ] method to return true or false. This is more graceful way of doing prerequisite check.

I know this AuthroizeAttribute is to check authorization, but we could mis-use it to validate any prerequisites until a better way is available.

/*****************************************************************************************/

using System;
using System.Web;
using System.Web.Mvc;

namespace WebApplication1.Controllers
{
internal class MustBeAuthorizedAttribute : AuthorizeAttribute
{
protected override bool AuthorizeCore(HttpContextBase httpContext)
{

if (preRequsitesFail)

{
return false;

}

return true;
}
}
}

/*****************************************************************************************/

[MustBeAuthorized]
public ActionResult Index()
{
return View();
}

/*****************************************************************************************/

Thanks to @philip instead of AuthroizeAttribute  ActionFilterAttribute is better. We could return any return value (e.g.. MethodNotAllowed, InternalServerError); see https://stackoverflow.com/questions/16822365/web-api-how-to-stop-the-web-pipeline-directly-from-an-onactionexecuting-filter 

notes, unit testing c# mock, stub, shim!

What to unit test?

Some times it feels why the heck are we adding this unit test? Some times did we really added at least minimum required unit tests or not?

I spent good amount of time researching this topic.

My thumb rule is :

Assume you are adding a document with samples directly taken from Unit tests (except Mocking part though) ; We want our Unit tests to test what customer typically do.

Unit Test is a shield:

Unit test works like a shield. It protects from the minute it is born. This unit test shield will protect the code from your future self. This unit test shield will also protect from others working on this piece of code. Mistakes which will break some existing user can be avoided with this unit testing strategy.

Mock Vs Fake(Stub/Shim)

Use whatever works! External DLLs are better faked. But there are some beasts which will have give tough fight to be faked. In that case do not directly call this external DLL, rather call via a thin layer, a layer with zero business logic but with an interface+class design. Then mock this layer instead of trying to fake your external DLL. Unit tests are saved!