Large corporations vs. Startups: A pov

In a short period of time, comparing 5 years to an entire career, I have worked in different environments; I started my career as an internal engineer at a large corporation, then I joined a startup company and lately I ended up doing consulting and I was placed again in a large corporation. Having gone through these commutations, I can clearly see the differences between each environment, the advantages and inconvenient of one to another.
Thus, the motivation for this post; I would like to share some insights from my modest experience, get a valuable feedback, and help those who are starting or just choosing to make a similar transition so they would know what to expect.

First, avoid the comparison trap

Before I go further, I would like to stop at this point. when you start thinking about making a job change, couple of thoughts might go around and come around, these thoughts are usually fulfilled with excitements, motivations and carefulness. But once the transition is done, we start to behave by instinct, and instinct drives us to compare the new situation with the previous one. Falling into this trap can really steal joy from your life…

What you like here is what you will miss there:

Generally speaking, in the game of changing jobs, there is always wins and losses, the things you like about your new job that you couldn’t have in your previous one are in the price of losing some of what you liked previously and vice-versa. The same will still apply if you are moving from a small company to a large one and conversely.
I personally have gone through this for both reasons – job change and environment change – so as a software engineer, I think the following points are to be considered.

  • Technology stack and methodologies of work
  • Company’s Hierarchy and evolution
  • Organization and processes
  • Coworkers friendliness and company’s culture
  • Company’s business and their selling philosophy
  • Role and value as a new employee in the company
  • And of course earnings and benefits

What’s good about small companies:

Working in a small company is like being in a family where everybody knows everybody, the advantage of that is that you know what everybody is doing, so you have an eye on how things work from the smallest detail to the head of the business. You’ll be likely having direct communications with VPs, CEOs and even founders. You will be sitting in voice range of HR, finance, strategy, customer service, etc…

Generally, start-ups are small but with big dreams, so you will be working with the future shakers of the world. As the competition is high with the so called “today’s giants”, you as a valuable resource in the company, will be used to do essential work to the success of the company; your work will make impact and you’ll be working daily on something that is customer facing and changes that come from your work affect the product directly. You also might be involved in different projects at the same time since it is very important to do things fast in a small company (time is money).

Finally, I consider that working in a small company is a unique opportunity to learn a lot of things. If you are making big work, you get faster growth, rewards and recognitions.

What’s good about large companies:

Being in a large company is like being a cell in a brain: you represent a small entity of the system with a well known set of tasks; you have few links via which you are allowed to communicate with higher management; any other communication should be made in connection chain following the so called “corporate process”. Inside a brain, billions of cells exist, pretty much like in a large companies where you have a big amount of resources available, up-to-date equipments and expert consultants. in addition to that you have in place best practices on getting things done; from projects, trainings to performance management. These best practices are set to ensure a better software quality.

Finally, It can be very prestigious to work at large companies and it will serve as an added notch on your resume.

What’s the best deal?

Obviously, there are pros and cons in both environments. although I personally recommend working at large companies in the beginning of a career to stretch your fields of knowledge technically, as well as to learn important skills such as project management and the best practices that go with that.
If you feel like your career development is going slow, then it is time to move to a small company; bringing with you the skills that you have developed, you can get a lot of high quality work accomplished quickly which will lead you to take more ownership of projects and also get experience leading teams that you wouldn’t get in larger companies. However it can come at an expense, that’s why it is really a trade off depending on what you want.

Since I recently started consultancy, I will be probably posting soon to let you know if it is a hit or a miss 🙂 .

Advertisements

An introduction to logic programming through Datalog

Why a post that goes about Datalog?

For those who do not have an idea about Datalog, I will start by answering this question “What is Datalog?”. And here I believe I won’t re-express things differently; to my knowledge Datalog contains a deductive database system. Queries and database updates are expressed using Datalog—a declarative logic language in which each formula is a function-free clause and every variable in the head of a clause must appear in the body of the clause. It is a non-procedural query language based on the logic-programming language Prolog. Mentioning Prolog, I would like to quote There is a flaw in the very foundations of Logic Programming: Prolog is non declarative”.

Then “Why Datalog?”:

  • Datalogis a language you will fall in love with
    • if you come with a fresh programming mind; you will believe that that’s the way programming should be
    • Or even if you come with a strong object oriented or procedural programming background,  then you will be amazed by the power of Datalog and how things are done differently.
  • Somehow, I think Datalog is sexy; a user describes the information desired without giving a specific procedure for obtaining that information.
  • Also Datalog simplifies writing recursive queries and makes query optimization easier.
  • And finally because as of today, if you use your favorite search engine and search for “Datalog” you probably won’t find what you were looking for.

The outline of this post is as follow:

  • Introduction to logic programming
  • Basic Structure/Terminology
  • Syntax of Datalog
  • Safety & recursion
  • Summary

A. Introduction to logic programming

In logic programming languages, programs are made up not of commands to be executed, but of definitions and statements about the problem to be solved. Declarative programs do not contain explicit instructions to be followed by the executing computer. Instead, the role of the computer is to manipulate the program’s information so as to derive the solution to a given problem. The goal of this post is to give a simple introduction to logic programming, and go in some details through Datalog.

B. Basic Structure/Terminology

Before we get too much further, let’s define a few terms.

  • Variables: A variable in Datalog is like a variable in a mathematical equation, it represents some constant that has yet to be determined.
  • Constants: A constant is an attribute value.
  • Facts: A fact is the same things a Tuple in a relation.
  • Rules: A rule is a way to derive new facts. It is part of a query.
  • Predicates: A predicate is a statement that may be true or false depending on the values of its variables; a predicate can take the role as either a property or a relation between entities.

C. Syntax of Datalog

Datalog syntaxes vary slightly depending on the implementation. Mainly Datalog is syntactically a subset of Prolog. This section contains a summary of the syntax of Datalog; my choice of the Datalog implementation goes for Datalog LB , — a LogicBlox’ commercial implementation of Datalog used for web-based retail planning and insurance applications

  • Declarations
family:person(p) -> .
declares person in the name-space family
family:person:is_male(p)->family:person(p).
family:person:is_female(p)->family:person(p).
declares is_male and is_female, can be read as males and females are persons
  • Constraints
!(family:person:is_male(p),family:person:is_female(p)).
!((!family:person:is_male(p),!family:person:is_female(p)),family:person(p)).
a person cannot be a male and female at the same time
a person must have a defined gender
family:person(p)->family:person:is_male(p);family:person:is_female(p).
this is also equivalent to saying that a person is male or a female, but it does not prevent a person from being both.
  • Relational predicates
family:brother(x,b)->family:person(x),family:person(b).
family:sister(x,s)->family:person(x),family:person(s).
family:parent(x,p)->family:person(x),family:person(p).
we define relations between two persons (one to many)
  • Functional predicates
family:father[x]=f->family:person(x),family:person(f).
family:mother[x]=m->family:person(x),family:person(m).
relations of type one to one are defined using functional predicates
family:person(p), family:person:id(p : id) -> string(id).
family:person:first_name[x]=f->family:person(x),string(f).
family:person:last_name[x]=l->family:person(x),string(l).
family:person:age[x]=a->family:person(x),uint[32](a).
functional predicates are used to define properties; the primary Key for person is the id. Datalog LB offers variety of simple types such as strings, integers, floats, dates …
  • Derivation rules
family:person:is_parent(p),family:person:is_father(p)<-
family:parent(_,p),family:person:is_male(p).
family:person:is_parent(p),family:person:is_mother(p)<-
family:parent(_,p),family:person:is_female(p).
family:parent(x,p)<-family:mother[x]=p;family:father[x]=p.family:brother(x,b)<-family:person:is_male(b),family:parent(x,p),family:parent(b,p),x!=b.
family:sister(x,b)<-family:person:is_female(b),family:parent(x,p),family:parent(b,p),x!=b.
In Datalog LB flipped arrows distinguish Integrity Constraints from derivation rules.
  • Run-time queries
+family:person:id(p : id),+family:person:is_male(p)<- id = “00-11-22-33-44”.
^family:person:first_name[p] = f_name<- f_name = “John”, family:person:id(p:id)<- id = “00-11-22-33-44”.
-family:person:id(p : id)<- id = “00-11-22-33-44”.
Run-time queries are not installed in the database, they can only be executed at a define run-time; The “+” is used to insert a new record in the database, The “^” is used to update a record, the “-” is used for removing the record.
The general form is
+|-|^R0(to,…tn ) <− R1(ko,…km),,, Rs(Jo,…Jp), tc=constT,kc=constK,…Jc=constJ .
.in SQL this is equivalent to (INSERT | DELETE | UPDATE ) XXX WHERE YYY.
  • Delta rules
family:person:kill(a,b)->family:person(a),family:person(b).
-family:person(p)<- +family:person:kill(_,p).
Delta rules are transactional rules (events) similar to queries but they can be installed in the system. For instance this rule removes the person p if he is killed by somebody.

D. Safety and recursion in Datalog programs

family:ancestor(x,a)->family:person(x),family:person(a).
family:ancestor(x,a)<-family:parent(x,a).
family:ancestor(x,a)<-family:parent(x,y),family:ancestor(y,a).

Recursive rules contains the same predicate in the head and the body or the rule. The power of Datalog resides in the recursion; Without recursion, Datalog can express all and only the queries of core relational algebra.
To ensure safety in Datalog programs, every rule should be safe in a way such as any variable occurring in the head of the rule must appear in the body (and vice versa).

E. Summary

Datalog is a restricted form of logic programming with predicates declarations, rules and constraints.
A Datalog rule has the form
R0(t0,1, . . . , t0,k0 ) <− R1(t1,1, . . . , t1,k1 ), . . . , Rn(tn,1, . . . , tn,kn).
Where R0 … Rn are predicate (relation) symbols.
Each term ti,j is either a constant or a variable (0 <= i <= n and 1 <= j <= ki).
The formula R0(t0,1, . . . , t0,k0 ) is called the head of the rule.
The sequence R1(t1,1, . . . , t1,k1 ) … Rn(tn,1, . . . , tn,kn) the body.
If n = 0, then the body is empty and the rule is called a fact.
A rule is safe if all variables occurring in the head also appear in the body.

In logic programming, the software engineer’s role is to create a real life model by declaring a collection of predicates and relations between these predicates and at a second stage to write a set of constraints and rules to solve the problem. The more rules we have, the more fun we get with Datalog since the executing computer uses these rules of inference to derive new formulas from the ones given in the program until it finds the one that expresses the solution.