"There is an old saying, "People join companies and leave bosses." Your relationship to your supervisor has a huge impact on whether you stay and flourish at your job or leave. It is the most important relationship you have at work. You are looking to build trust with your boss."
insights about software development
Friday, August 17, 2018
Saturday, August 11, 2018
How to Code Fast
I am a Software developer with massive experience in .Net framework. I worked in a startup and small software business. I am currently working in a big global company specialized in enterprise softwares for its customers.
We must code as quickly as we can. We think fast on problem giving by manager. I have already thoughts how can we be fast enough. I also did a little research and noticed my thoughts are useful in fast coding. I left the links below of the page.
It isn’t normal unless you have got 10 years plus experience. If you have got less than 5 years experience and you’re coding slow I think it is normal by depeding person. Key is to work hard. Never give up.
Solution is really simple. Just PRACTICE after work. I think the only way to write fast code is to practice coding on weekends and after work. Learn new things, think about problems and design a solution.
Other idea is being an agile person. Eating healthy food makes you feel good so your brain will get the necessary energy it needs. Go out and get a hobby. These things will make you think properly and code fast.
The thing we care is that we want simple code.
Check out below links:
https://www.quora.com/How-do-programmers-code-quickly
https://softwareengineering.stackexchange.com/questions/65705/how-to-code-faster-without-sacrificing-quality
https://www.codesimplicity.com/post/the-secret-of-fast-programming-stop-thinking/
We must code as quickly as we can. We think fast on problem giving by manager. I have already thoughts how can we be fast enough. I also did a little research and noticed my thoughts are useful in fast coding. I left the links below of the page.
It isn’t normal unless you have got 10 years plus experience. If you have got less than 5 years experience and you’re coding slow I think it is normal by depeding person. Key is to work hard. Never give up.
Solution is really simple. Just PRACTICE after work. I think the only way to write fast code is to practice coding on weekends and after work. Learn new things, think about problems and design a solution.
Other idea is being an agile person. Eating healthy food makes you feel good so your brain will get the necessary energy it needs. Go out and get a hobby. These things will make you think properly and code fast.
The thing we care is that we want simple code.
Check out below links:
https://www.quora.com/How-do-programmers-code-quickly
https://softwareengineering.stackexchange.com/questions/65705/how-to-code-faster-without-sacrificing-quality
https://www.codesimplicity.com/post/the-secret-of-fast-programming-stop-thinking/
Thursday, March 15, 2018
Refactoring
Hello,
I have been reading Pragmatic Programmer which is my one of the favorite book. I will share the ideas of refactoring. Let's start.
I am going to touch on refactoring in software development in this post. I am going to mention my job experiences which are good examples of refactoring.
Construction or gardening?
Software construction is an old-style common term in software development.
Le's define what refactoring is according to Uncle Bob:
Rewriting, reworking and re-architecting code are collectively known as refactoring.
When do we refactor?
Me: Hi boss. I finished the ABC module which is quite hard. The code works but I need another week to refactor it.
Boss: Hi Erol. Let me test this module so I can understand if it works well. Hmm. Well done. The code seems to work well and we are going to have a demo on Friday to a client. Our time is limited. Deploy it to the server.
Me: Ohh. For sure I am going to make it.
About two weeks later:
Me: Seriously? This code seems like a spaghetti code. I am really bored. I need to have a break and time to refactor it. Truth is there are tons of jobs that I really have to care. On the other hand, I have a god class, ugly code which is not functional and modular.
Boss: Erol. Do you remember that you have done module from last week? It worked when we present to a client but the problem is we found a bug. As you know bug-fix is an important issue. We don't want to bother our customer in the production env. Could you give up your current task and figure out the problem?
Me: I am sorry to hear that. Sure I will take a look at it. After about 5 minutes I will have done it and deploy to the production server.
So, unfortunately, we have a cycle between two of us. We have the stumbling block. We lost our valuable time.
What does R.Martin suggest?
We had a communication a problem and time excuse to refactor in coding. As a programmer who read the book Pragmatic Programmer, I suggested the idea of Uncle Bob. My boss is quite fine when hears the thoughts.
I try to write my code. I do my tests until I see green. (TDD) Then I do refactoring in coding. After than that, I write code for production code. I let my boss how much time it takes. So he/she can give a deadline for the client.
Check out the links about refactoring. Let me know what do you think.
Important terms:
I have been reading Pragmatic Programmer which is my one of the favorite book. I will share the ideas of refactoring. Let's start.
I am going to touch on refactoring in software development in this post. I am going to mention my job experiences which are good examples of refactoring.
Construction or gardening?
Software construction is an old-style common term in software development.
- - Decide what you want to build. Draw up a blueprint.
- - Build the superstructure, and apply finishing touches.
- - Move in and call for building maintenance to fix any problems.
Le's define what refactoring is according to Uncle Bob:
Rewriting, reworking and re-architecting code are collectively known as refactoring.
When do we refactor?
- Experience engineer to newbie engineer sometimes we duplicate our code which is not a good practice at all. It is against to DRY principle. Don't Repeat Yourself.
- The code can change according to our knowledge and our technology. Keeping up is a good practice. It solves the security problems and performance which come up in the future. (Outdated knowledge)
- When we want a readable and clean code we need to refactor our code. I can be the design of the code.
Refactor Early, Refactor Often...
Real World ScenarioMe: Hi boss. I finished the ABC module which is quite hard. The code works but I need another week to refactor it.
Boss: Hi Erol. Let me test this module so I can understand if it works well. Hmm. Well done. The code seems to work well and we are going to have a demo on Friday to a client. Our time is limited. Deploy it to the server.
Me: Ohh. For sure I am going to make it.
About two weeks later:
Me: Seriously? This code seems like a spaghetti code. I am really bored. I need to have a break and time to refactor it. Truth is there are tons of jobs that I really have to care. On the other hand, I have a god class, ugly code which is not functional and modular.
Boss: Erol. Do you remember that you have done module from last week? It worked when we present to a client but the problem is we found a bug. As you know bug-fix is an important issue. We don't want to bother our customer in the production env. Could you give up your current task and figure out the problem?
Me: I am sorry to hear that. Sure I will take a look at it. After about 5 minutes I will have done it and deploy to the production server.
So, unfortunately, we have a cycle between two of us. We have the stumbling block. We lost our valuable time.
What does R.Martin suggest?
"You might want to explain this principle to the boss by using a medical analogy: think of the code that needs refactoring as a “growth.” Removing it requires invasive surgery. You can go in now, and take it out while it is still small. Or, you could wait while it grows and spreads—but removing it then will be both more expensive and more dangerous. Wait even longer, and you may lose the patient entirely." - Pragmatic Programmer
We had a communication a problem and time excuse to refactor in coding. As a programmer who read the book Pragmatic Programmer, I suggested the idea of Uncle Bob. My boss is quite fine when hears the thoughts.
I try to write my code. I do my tests until I see green. (TDD) Then I do refactoring in coding. After than that, I write code for production code. I let my boss how much time it takes. So he/she can give a deadline for the client.
Check out the links about refactoring. Let me know what do you think.
Important terms:
Software Rot, Code RotSoftware Entropy
Sunday, December 31, 2017
Is the Daily Stand-Up meeting important?
I would like to share my thoughts about Daily Stand-up meetings in agile development. I am going to touch on advantages/disadvantages without going into detail.
If you're familiar with Scrum, you probably heard 'Daily Stand-up Meeting' before. Even though I have a bit more than 1 year of experience as an Intern Student at startups, I can say that these daily magical meetings bring you adequate work environment. Let's look at why is it good for companies? Basically, meetings mean communication that means the key to the progression so then the company can go forward. Taking action is always an important matter in life as well as while developing a project. Making these meetings are important because this a time that the whole team is together so the team can argue what was the outcome and where we are now in terms of product. The result can give the best possible output. Actually, this is one of the cycles of the agile methodology. It can carry you to the next level.
Basically following lines are important:
- What did you do yesterday?
- Have you done something or do you still continue to work?
- Did you encounter any problem while you were doing it?
- What are you gonna do today?
When your turn comes up, just say basic things. Force yourself to be up and tell them your speech. Don't say very complex sentences because this is not a competition and time is valuable. If you have trouble with something, tell them and maybe they know the solution. You should also say if you comment something or rename a function name.
Let me know if it makes sense to you, leave a comment.
If you're familiar with Scrum, you probably heard 'Daily Stand-up Meeting' before. Even though I have a bit more than 1 year of experience as an Intern Student at startups, I can say that these daily magical meetings bring you adequate work environment. Let's look at why is it good for companies? Basically, meetings mean communication that means the key to the progression so then the company can go forward. Taking action is always an important matter in life as well as while developing a project. Making these meetings are important because this a time that the whole team is together so the team can argue what was the outcome and where we are now in terms of product. The result can give the best possible output. Actually, this is one of the cycles of the agile methodology. It can carry you to the next level.
Basically following lines are important:
- What did you do yesterday?
- Have you done something or do you still continue to work?
- Did you encounter any problem while you were doing it?
- What are you gonna do today?
When your turn comes up, just say basic things. Force yourself to be up and tell them your speech. Don't say very complex sentences because this is not a competition and time is valuable. If you have trouble with something, tell them and maybe they know the solution. You should also say if you comment something or rename a function name.
Let me know if it makes sense to you, leave a comment.
Saturday, December 16, 2017
Software: Naming requires creativity
In this first blog post, I am going to focus on naming variables/functions in software development. Why I want to talk about this is I was listening podcast and there were lots of ideas that make me think deeply about naming. You can check it out the podcast from this link: http://www.se-radio.net/2016/12/se-radio-episode-278-peter-hilton-on-naming/ I highly recommend listening to this podcast.
Let's go ahead through the important bits that run into as I was listening podcast.
Peter Hilton is a writer, and British mathematician he wrote 'Play for Scala' book which is very famous when it comes to web development on PlayFramework/Java.
It was fun to listen because the first question asked by the interviewer is that why naming is so hard? It must be quite straightforward because this is just naming something and the answer was also surprising given by Peter Hilton. Naming is one of the hardest things in software development like validation and caching.
He was saying that naming is an important subject and one of the most challenging thing that you might come across when you build the software systems. It requires creativity. When you create a variable you have to think a bit about the words. The code is for human communication as well as machine communication.
For instance, when you name a function it must be summary of the function. You shouldn't use popular words like Get something or DoSomething because function aims to make something actually. I wanna get the data from somewhere FetchWeatherData, Calculate/Divide are better options instead of using GetSomething. You should avoid using data as well because basically everything can be a data and it is not clear what you mean. Reasonable naming does your code seems like a poem in terms of readability.
Another thing that he was saying that it's better to name in time. Renaming might be harder than name something, in that case, we should think about naming as much as we can do. I think
The idea that sums up the entire text is that you need to think twice when we name something.
So, what do you think? Any idea is welcome.
Suggested book:
https://www.amazon.com/Clean-Code-Handbook-Software-Craftsmanship/dp/0132350882 / Clean Code from Uncle Bob. It has a chapter named Naming for further information.
Let's go ahead through the important bits that run into as I was listening podcast.
Peter Hilton is a writer, and British mathematician he wrote 'Play for Scala' book which is very famous when it comes to web development on PlayFramework/Java.
It was fun to listen because the first question asked by the interviewer is that why naming is so hard? It must be quite straightforward because this is just naming something and the answer was also surprising given by Peter Hilton. Naming is one of the hardest things in software development like validation and caching.
He was saying that naming is an important subject and one of the most challenging thing that you might come across when you build the software systems. It requires creativity. When you create a variable you have to think a bit about the words. The code is for human communication as well as machine communication.
For instance, when you name a function it must be summary of the function. You shouldn't use popular words like Get something or DoSomething because function aims to make something actually. I wanna get the data from somewhere FetchWeatherData, Calculate/Divide are better options instead of using GetSomething. You should avoid using data as well because basically everything can be a data and it is not clear what you mean. Reasonable naming does your code seems like a poem in terms of readability.
Another thing that he was saying that it's better to name in time. Renaming might be harder than name something, in that case, we should think about naming as much as we can do. I think
The idea that sums up the entire text is that you need to think twice when we name something.
So, what do you think? Any idea is welcome.
Suggested book:
https://www.amazon.com/Clean-Code-Handbook-Software-Craftsmanship/dp/0132350882 / Clean Code from Uncle Bob. It has a chapter named Naming for further information.