|
|
|
everything is computerized now-a-days and as developers we should care about how our product looks from the user's perspective. working 1:1 with the clients helps with it.
there are some projects, some businesses which would have been the industry leaders had they started five years later. one has to find out if the world is ready for it.
this is more applicable to languages or other things which require standardization. starting out with a specification is a bad idea and it's better to test a few approaches in the real world first and see which one works better and which one does't and why. based on that the specification should be designed.
code reading sessions are quite important where each programmer explains their code line by line and others take notes on what was easy and what could have been better, things like "that comment looks confusing to me". a few hours of code reading can save weeks of qa.
it helps keep the project on track where you see who has made what progress and avoid situations where some dev says around the deadline "yeah i am almost done" and then you find that their code is crap and it does nothing. this way you avoid delays.
but it requires some teaching, mutual trust and well defined boundaries. in a dysfunctional team, people would tear each other apart in such meetings and it's a nice way figure this out pretty quickly.
clean it up first, organize it and format it properly, separate out the components and in the process you have already familiarized yourself with the code, then you would know where to start from. a consistent coding style helps with readability, good code will definitely be readable.
if it's getting a little trickier and the readibility is being compromised then choose readability over the neat trick. if it's some critical inner for loop code which requires some neat trick to work efficiently then write a lot of comments around it explaining what the trick is.
people optimize in the wrong places and that optinization adds complications to the code. usually in the code there are hotspots which need to be really efficient and it's fine if rest of the code is a little inefficient.
this helps prevent big rewrites which often lead to second-system problem. if you don't cleanup, some day it will need a rewrite. throw it all and rewrite should only be done when you know that something went wrong and the code base has become unworkable.... and it would be faster to just replace it than to fix it.
the existing code contains bits of embedded knowledge that you don't think of when you say "we can just rewrite it". instead the incremental approach works out where you replace only the part which you fully understand, one at a time.
document your code as you most probably won't remember the context the next time you see it and sometiomes you will find stuff that you wrote and you will be amazed at what you wrote.
a good understanding of the human language is very important as programmers as we are constantly writing emails, code, plans, specifications, documentation. make sure that you are good at reading and writing your mother tongue and the common language of communication at workplace.
this connects to the previous point "specifications should follow implementations". if specification/api comes first and it's too liberal then it's going to become a mess at some point as there would be too many things to manage and then it's impossible to remove it.
it's not that distant and yet people don't know of the discussions around various decisions and the arguments in favour and against certain things which turned out to be good or bad. we lack curiosity about where this stuff that we are using came from
invite the candidate with the piece of code that he is really proud of and make them walk through it, observe the quality of presentation and see the thing which he is proud of, can they communicate that thing.
read a lot of good books, find out some good websites and read those (although there's more crap now-a-days), focus on communication, learn to write and read. understand data structures well, can you put an algorithm in code?
everything is connected but there's just a lot of noise at this point, it's still evolving and the next iteration might be something different.
when we went from time sharing to personal computers, we lost the social aspect, people using time sharing were in a community... now we got that back with irc and open source but the state of security is still sad, there are programs on your computer which don't work for your interests.
testing is quite important as a project matures and as more and more people start working on it. it enforces invariants. you are the lifetime maintainer of the code that you write.
if there is a choice between taking down the service for a week to fully migrate and to slowly do it over a period of two months, then taking the second approach would be a better idea. avoid downtime if there is any other alternative. after the first 10% migration, things will be fast again and then you can speed up the migration.
when you are dealing with invariant violation between your code and the user code, then you don't crash and keep going for as long as you can. when you are dealing with invariant violation between your code, then you blow up loud.
no it doesn't, it's not supported by your kernel version and the vm may be hiding that from you by giving you some abstraction which makes it look like it's efficient, but it's only efficient on this version of kernel.
start with the common queries, the mockups and then flesh them out.
create specs.txt as the first file and add pseudocode of the
implementation to it. this works quite well for backend technologies,
or things which you are familiar with. sometimes there are hard bits
which you are unsure of, you should first create small prototypes to
test them and only then add about them to specs.txt.
doing hard things feels great, you expand your area of comfort. reading other's code, you find different ways of doing something, which often are qutie neat. i once was looking through icecc codebase and i found that they were using this macro with two case labels instead of one and this macro switched between them based on the api version. i found it pretty neat.
when asking for change in someone else's project, don't ask it as "i want feature x", most probably the maintainer would say "go away, i am busy". a better way to ask is "i want to add x and i was thinking of something like {a patch}, what do you think?" they would know that you are serious about it and would correct you if you are using the wrong approach.
when you work on things that you enjoy, you would find that you are always excited to work on it and burnout is less of a problem for you. then routine becomes a secondary thing, you sleep when it's required and you prefer working during the night... those are good times in a programmer's life.
they help you get focused about the thing, but if in teams the whole team should be on the same page or else you feel bad because someone else didn't do their work
there are some who don't do anything on their own, they work on tasks and then move to other tasks assigned to them, or just browse the web when they are done with their tasks. these people don't really have passion for excellence.
such people are good hires, those who work in their own time on things which weren't asked of them, some side project. they would have maintainence stories and debugging horror stories about it.
we as programmers work with these computers yet we lack basic knowledge about how the numbers, the floats are stored, how is multiplication, division happening inside the cpu, how does the computer allocate memory.
a successful implementation means that you understand the concept pretty well or else how could you have translated form human language into programming language.
make sure that the debugger command is right, that the thing you are
investigating is what you think it is, once there was this bug in my
cpp code and the error was cryptic.. and it was because a using namespace weld declaration that i had written and i thought that i
never wrote that code. always git status your code
it's true for small number of machines that a programmer's time is worth something but when you go distributed, all the sudden it's worth nothing compared to the number of machines it's going to be deployed against. now write it in c, profile the hell out.
when looking at other's code, the better approach is to not directly start including it in your code but build a small hello world example first, then learn about which parts you need out of it and unit test that. once you are satisfied by it, you can include it in your code.
others might do it for a job and don't really enjoy it whereas the hardcore programmers put in 10 time the amount of work and are thinking about it when they are not working.
it's quite possible that the bug you are investigating never comes to light when seen through the lense of gdb as it might be a timing or async operation related bug and by stopping at a breakpoint, you just the conditions favourible for the bug.
the most important thing good programmers have is curiosity. they always hack around the code in their free time and are always keen to know "how does that work".
worst is better says "build a good enough product and get it out to the user as soon as possible". then with each release add more features and improve the existing ones. unittests are good to have but they are not critical to the project and so atleast in the initial stages can be avoided as otherwise it slows the development process.
it's better to go v1 in first 6 months and then have 5 more release during the next few years than to take the 3 years for the v1 release.
before starting the project, have a list of things which you want in v1 and later, and then start working on one at a time. out of all, choose the one which gets you to a working prototype as soon as possible, like a window with a button as then you would know where to go from there.
small teams of motivated people work the best, there's direct communication and less "organization" of manpower. when there are arguments, people can quickly defend their opinions and reach a conclusion without having to create a committee each time someone disagrees.
creating a software for one platform first (like windows) and then porting it to other platforms is a bad idea. then the ports will always be a second class implementation in the shadow of the first one as the original interface would be biased towards the first platform's api.
people need to take the ownership of code that they write. the sense of a ownership of the code as an individual is more important than as a team as then people know whom to approach when things fall apart. when a team owns the code then it's no one's mistake.
