web developer & system programmer

coder . cl

ramblings and thoughts on programming...


filtering companies

published: 30-10-2012 / updated: 30-10-2012
posted in: development, programming, projects, rants, tips
by Daniel Molina Wegener

As you know, I use a well defined set of questions to filter where should I work. If the company does not pass the test, I usually ignore that job offering. For example if I ask “what is your current distributed version control system?” and their answer is “SVN”, they got banned immediately — you know what I mean. The set of questions is pretty simple, and since you are usually interviewed by someone who is hiring or filtering the candidacies, you can do the same asking questions. For example, I am not interested in the company name; it can be Microsoft, but if they tell me “we are using visual source safe”, I do not handle that job offering. For me what is doing and what is using a company is important, because that will tell you how good are they doing their job.

programming at fifty

published: 28-10-2012 / updated: 28-10-2012
posted in: development, programming, projects, rants, tips
by Daniel Molina Wegener

There are three very objective posts about programming at fifty, probably with controversial opinions about being a programmer at fifty. Each post with some truth behind it, but in my opinion the solution to keep working as a programmer at fifty in a safe environment is to be more selective in the type of job that you choose. In the first post, I get the idea that you will be working — if you are working on the consumer applications market — in an ocean of APIs, and the fact that you can’t ever lose the hunger to know more, and almost every task as programmer depend on the involved market. Job filtering is an option, a real option. I currently do not handle any kind of project, and I use very consistent filters.

programming requires thinking

published: 19-10-2012 / updated: 19-10-2012
posted in: development, programming, projects, rants, tips
by Daniel Molina Wegener

Programming requires thinking. You must place instructions correctly, with a logical order, and you must prove that your program will produce the right behaviour. Even doing tests, your programs can fail, so you can use code hardening or similar techniques to avoid errors. The inclusion of a program verification is engaging, but it is limited to prove a limited set of features, even if that verification is made formally, you will need to make remarkably different types of tests to check the program correctness. So, the main problem with programming is reaching correctness, and how do you need to be concentrated to avoid programming mistakes, like passing null pointers to some function, because a program can compile, but cannot work.

side projects

published: 12-10-2012 / updated: 12-10-2012
posted in: development, programming, projects, rants, tips
by Daniel Molina Wegener

As a software developer, who has a side project — open source or not — is a software developer that can make products. If the developer can identify a community need, and produce a product, there is no problem for that developer to understand a specification and meet the desired specification. Also, the developer will be able to satisfy the correct solution and will be able to meet any observations about the requirements and the source code.

the problem with web development

published: 06-10-2012 / updated: 06-10-2012
posted in: development, programming, rants, tips
by Daniel Molina Wegener

If you are a programmer, you are probably working on web development. Almost every application that is being launched to the market is a web based application or a mobile application with a background web platform supporting it. From that point, almost every job option related to software development is strongly linked to web development, and I think that the web development market is a little bit messy, mainly due to the lack of technical knowledge of people that are hiring developers. Just naming the required technology enough times to make your resume to pass the filter in the job position is a good start point to getting hired. Is that enough to meet the job requirements?. On software development experience is not so required, and seems to be strongly required by some companies hiring developers.

type safety is not security

published: 02-10-2012 / updated: 02-10-2012
posted in: c, development, haskell, programming, rants, tips
by Daniel Molina Wegener

Standar ML is defined as safe using the following definition «ML is safe, in that a program that passes the type-checker cannot dump core, access private fields of abstract data types, mistake integers for pointers, or otherwise “go wrong.”». A type-checker verifies that each term used in the programming language should have the correct type once it is used. For example if a function is defined to receive an integer type, once it is called, an integer term should be used, otherwise the compiler may throw an error and the execution “goes wrong”. If the type-checking algorithm accepts the program, then it is well-typed. When a programming language has a type-checking algorithm on its compiler, we call it statically-typed. Dynamic typing does not have a type checker on its compiler, you can write the same function, it will not have any sentence defining an input type, and it will be able to receive a string when an integer is required.

everything is about programming

published: 04-08-2012 / updated: 04-08-2012
posted in: development, programming, projects, rants, tips
by Daniel Molina Wegener

There are some myths about programming and development methodologies. Among several of those myths, the one that makes laugh a lot is that one that claims that “you do not need skilled programmers to build successful software”. I really cannot imagine a team of non skilled programmers doing a successful application. Most myths are claiming that “the used methodology and management is more important than having good programmers”. Then CMMI, Agile, and several points of view about developing applications and systems are applied daily in software development. But more than the methodology itself, the fact that communications and skilled programmers are making great teams, cannot be denied.